| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 18, 2005.
Copyright © The Internet Society (2005).
This document describes the state machines for the General Internet Messaging Protocol for Signaling (GIMPS). The states of GIMPS nodes for a given signaling flow and their transitions are presented in order to illustrate how GIMPS may be implemented.
1.
Introduction
2.
Terminology
3.
Notational conventions used in state diagrams
4.
State Machine Symbols
5.
Common Rules
5.1
Common Procedures
5.2
Common Variables
5.3
Constants
6.
State machine for GIMPS querying node
7.
State machine for GIMPS responding node
8.
Security Considerations
9.
Open Issues
10.
Contributors
11.
Acknowledgments
12.
References
12.1
Normative References
12.2
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
This document describes the state machines for GIMPS [1] (Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” February 2005.), trying to show how GIMPS can be implemented to support its deployment. The state machines described in this document are illustrative of how the GIMPS protocol defined in [1] (Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” February 2005.) may be implemented for the GIMPS nodes in different locations of a flow path. Where there are differences [1] (Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” February 2005.) are authoritative. The state machines are informative only. Implementations may achieve the same results using different methods.
There are two types of possible entities for GIMPS signaling:
GIMPS querying node - GIMPS node that initiates the discovery of the next peer;
GIMPS responding node - GIMPS node that is the discovered next peer;
We describe a set of state machines for these entities to illustrate how GIMPS may be implemented.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
The following text is reused from [3] (Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, “State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator,” December 2004.) and the state diagrams are based on the conventions specified in [4] (Institute of Electrical and Electronics Engineers, “DRAFT Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control (Revision),” January 2004.), Section 8.2.1. Additional state machine details are taken from [5] (Ohba, Y., “State Machines for Protocol for Carrying Authentication for Network Access (PANA),” February 2005.).
The complete text is reproduced here:
State diagrams are used to represent the operation of the protocol by a number of cooperating state machines each comprising a group of connected, mutually exclusive states. Only one state of each machine can be active at any given time.
All permissible transitions between states are represented by arrows, the arrowhead denoting the direction of the possible transition. Labels attached to arrows denote the condition(s) that must be met in order for the transition to take place. All conditions are expressions that evaluate to TRUE or FALSE; if a condition evaluates to TRUE, then the condition is met. The label UCT denotes an unconditional transition (i.e., UCT always evaluates to TRUE). A transition that is global in nature (i.e., a transition that occurs from any of the possible states if the condition attached to the arrow is met) is denoted by an open arrow; i.e., no specific state is identified as the origin of the transition. When the condition associated with a global transition is met, it supersedes all other exit conditions including UCT. The special global condition BEGIN supersedes all other global conditions, and once asserted remains asserted until all state blocks have executed to the point that variable assignments and other consequences of their execution remain unchanged.
On entry to a state, the procedures defined for the state (if any) are executed exactly once, in the order that they appear on the page. Each action is deemed to be atomic; i.e., execution of a procedure completes before the next sequential procedure starts to execute. No procedures execute outside of a state block. The procedures in only one state block execute at a time, even if the conditions for execution of state blocks in different state machines are satisfied, and all procedures in an executing state block complete execution before the transition to and execution of any other state block occurs, i.e., the execution of any state block appears to be atomic with respect to the execution of any other state block and the transition condition to that state from the previous state is TRUE when execution commences. The order of execution of state blocks in different state machines is undefined except as constrained by their transition conditions. A variable that is set to a particular value in a state block retains this value until a subsequent state block executes a procedure that modifies the value.
On completion of all of the procedures within a state, all exit conditions for the state (including all conditions associated with global transitions) are evaluated continuously until one of the conditions is met. The label ELSE denotes a transition that occurs if none of the other conditions for transitions from the state are met (i.e., ELSE evaluates to TRUE if all other possible exit conditions from the state evaluate to FALSE). Where two or more exit conditions with the same level of precedence become TRUE simultaneously, the choice as to which exit condition causes the state transition to take place is arbitrary.
In addition to the above notation, there are a
couple of clarifications specific to this document. First,
all boolean variables are initialized to FALSE before the
state machine execution begins. Second, the following
notational shorthand is specific to this document:
- <variable> = <expression1> | <expression2> | ...
- Execution of a statement of this form will result in <variable> having a value of exactly one of the expressions. The logic for which of those expressions gets executed is outside of the state machine and could be environmental, configurable, or based on another state machine such as that of the method.
| TOC |
- MA
- means "Messaging Association"
- Upstream/Downstream MRS:
- means "Message Routing State with upstream/downstream peer state info"
- ( )
- Used to force the precedence of operators in Boolean expressions and to delimit the argument(s) of actions within state boxes.
- ;
- Used as a terminating delimiter for actions within state boxes. Where a state box contains multiple actions, the order of execution follows the normal language conventions for reading text.
- =
- Assignment action. The value of the expression to the right of the operator is assigned to the variable to the left of the operator. Where this operator is used to define multiple assignments, e.g., a = b = X the action causes the value of the expression following the right-most assignment operator to be assigned to all of the variables that appear to the left of the right-most assignment operator.
- !
- Logical NOT operator.
- &&
- Logical AND operator.
- ||
- Logical OR operator.
- if...then...
- Conditional action. If the Boolean expression following the if evaluates to TRUE, then the action following the then is executed.
- \{ statement 1, ... statement N \}
- Compound statement. Braces are used to group statements that are executed together as if they were a single statement.
- !=
- Inequality. Evaluates to TRUE if the expression to the left of the operator is not equal in value to the expression to the right.
- ==
- Equality. Evaluates to TRUE if the expression to the left of the operator is equal in value to the expression to the right.
- >
- Greater than. Evaluates to TRUE if the value of the expression to the left of the operator is greater than the value of the expression to the right.
- <=
- Less than or equal to. Evaluates to TRUE if the value of the expression to the left of the operator is either less than or equal to the value of the expression to the right.
- ++
- Increment the preceding integer operator by 1.
| TOC |
Throughout the document we use terms defined in the [1] (Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” February 2005.), such as Query, Response, Confirm.
State machine represents handling of GIMPS messages that match a Message Routing State's MRI and NSLPID and with no protocol errors. Separate parallel instances of the state machines should handle messages for different Message Routing States.
The state machine states represent the upstream/downstream peers states of the Message Routing State.
For simplification not all objects included in a message are shown. Only those that are significant for the case are shown. State machines do not present handling of messages that are not significant for management of the states.
Presented in this document state machines do not cover all functions of a GIMPS node. Functionality of message forwarding, ROA processing, transmission of NSLP data without MRS establishment and providing of the received messages to the appropriate MRS, we refer as "Lower level pre-processing" step. The interaction of this step with the presented here state machines is defined as follows:
Pre-processing provides to the appropriate MRS FSM only the messages which are matched against waiting Query/Response cookies, or established MRS MRI+NSLPID primary key. This is presented by "rx_*" events in the state machines.
- Tg_SendMsg:
- NSLP/GIMPS API message that request transmission of a NSLP message
- Tg_SetStateLifetime(time_period):
- NSLP/GIMPS API message providing info for the Lifetime of an RS, required by the application. "Time_period = 0" represents the cancellation of established RSs/MAs (invoked by NSLP application).
- Tg_MessageDeliveryError:
- NSLP/GIMPS API message informing NSLP application of unsuccessful delivery of a message
- Tg_RecvMsg:
- NSLP/GIMPS API message that provides received message to the NSLP
- Tg_NetworkNotification:
- NSLP/GIMPS API message that informs NSLP for change in MRS
- Tx_Query_Dmode:
- Transmit of Query message in Dmode
- Tx_Response_Dmode:
- Transmit of Response message in Dmode
- Tx_Confirm_Dmode:
- Transmit of Confirm message in Dmode
- Rx_Query_Dmode:
- Receive of Query message in Dmode
- Rx_Response_Dmode:
- Receive of Response message in Dmode
- Rx_Confirm_Cmode:
- Receive of Confirm message in Dmode
- Tx_Response_Cmode:
- Transmit of Response message in Cmode (via MA)
- Tx_Confirm_Cmode:
- Transmit of Confirm message in Cmode (via MA)
- Rx_Response_Cmode:
- Receive of Response message in Cmode (via MA)
- Rx_Confirm_Cmode:
- Receive of Confirm message in Cmode (via MA)
- Queue NSLP msg info:
- Save NLSP messages in a queue until a required MA association is established
- Tx_Msg_Cmode:
- Transmit message in Cmode (via MA)
- Rx_Msg_Cmode:
- Receive message in Cmode (via MA)
- Tx_Msg_Dmode:
- Transmit message in Dmode
- Rx_Msg_Dmode:
- Receive message in Dmode
- TIMEOUT_MRSlifetime:
- Expiration of the lifetime timer of the upstream/downstream peer state info of the Message Routing State.
- TIMEOUT_MRS+MA_lifetime:
- Expiration of the lifetime timer of the upstream/downstream peer state info of the Message Routing State, where MA is used.
- TIMEOUT_Refresh:
- Refresh interval timer expiration
- TIMEOUT_WaitResponse:
- Expiration of Timer for the waiting period for Response message
- TIMEOUT_WaitConfirm:
- Expiration of Timer for the waiting period for Confirm message
- Install downstream/upstream MRS:
- Install new Message Routing State and save the corespoding peer state info (IP address and UDP port or pointer to the used MA) for the current Message Routing State or update the coresponding peer state info.
- DELETE MRS:
- Delete installed downstream/upstream peer's info for the current Message Routing State and delete the Message Routing State if required.
- Establish MA:
- Establish Message Association (MA) between current node and its downstream peer
- Established MA:
- A Message Association (MA) is established between the current node and its upstream peer. The initiator for the establishment is the upstream peer. Re-use existing MA: An existing MA between the current node and its peer is re-used
- DELETE MA:
- Delete/disconnect used MA
- Stop using shared MA:
- Stop using shared MA. If the shared MA is no more used by any other MRSs, it depends on the local policy whether it is deleted or kept.
- REFRESH MRS:
- Refreshes installed MRS.
- Tg_MA_Error:
- Error event with used MA.
- Tg_PathChange:
- External event for Path change detected.
- Tg_Establish_MA:
- Trigers establishment of MA.
- Tg_MA_Established:
- MA has been successfully established.
- Tg_ERROR:
- General Error event / system level error.
- No_MRS_Installed:
- Error response, send by the Responding node indicating lost Confirm message.
It is assumed that the type of mode and destination info (which need to be taken from the application parameters and local GIMPS policy) is provided. This is represented by the common variables Dmode, Cmode, MAinfo, MApresent and Refresh.
- Dmode:
- The message MUST be transmitted in Dmode. This is specified by "Message transfer attributes" set to the following values:
- Reliability:
- is set to FALSE
- Security:
- is set to values that do not request special security handling of a message.
- Local processing:
- is set to values that do not require services offered by Cmode [1] (Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” February 2005.)
- Cmode:
- The message MUST be transmitted in Cmode. This is specified by "Message transfer attributes" set to any of the following values:
- Reliability:
- is set to TRUE
- Security:
- is set to values that request secure handling of a message.
- Local processing:
- is set to values that require services offered by Cmode (e.g., congestion control) [1] (Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” February 2005.)
- MAinfo:
- GIMPS message parameters describing the required MA or proposed MA e.g. "Stack-proposal" and "Node-addressing". This list of GIMPS parameters is not complete. A full mapping is left for future version of the document.
- NSLPdata:
- NSLP application data.
- RespCookie:
- Responder Cookie that is being sent by the Responding node with the Response message in case that its local policy requires a confirmation from the querying node.
- Refresh:
- This variable specifies that the message is for refresh purposes
- ConfirmRequired:
- TConfirm message is required by the local policy rule for installation of the new MRS.
- NewPeer:
- Response message is received from new responding peer.
- MAexist:
- Existing MA will be reused.
- CheckPeerInfo:
- The sender of the received data message is matched against the installed peer info in the MRS.
- UpstreamPeerInstalled:
- Upstream peer info is installed in the MRS.
| TOC |
-----------
State: IDLE
-----------
Condition Action State Note
------------------------+-------------------------+-----------+---
(tg_SendMsg)&&(Dmode) |Tx_Query |Wait |1)
|Queue_NSLP_msg_data |Response |**
| | |
(tg_SendMsg)&&(Cmode) |Tx_Query(MAinfo) |Wait |1)
|Queue_NSLP_msg_data |Response |
| | |
------------------------+-------------------------+-----------+---
-------------------
State: WaitResponse
-------------------
Condition Action State Note
------------------------+-------------------------+-----------+---
(rx_Response_Dmode)|| |Install MRS |Established|**
((rx_Response_?mode( |If (RespCookie) |Downstream |2)
MAinfo)&&(MAexist))| tx_Confirm_?mode(Resp |MRS |
| Cookie)| |
|Tx_queued_Msg_?mode | |
| | |
(rx_Response_?mode( |Tg_Establish_MA |Wait MA |*
MAinfo)&&(!MA_exist))|(Tx_Confirm_?mode) |Establish. |2)
| | |
rx_Msg_?mode |IF(CheckPeerInfo) |Wait |8)
| Tg_RecvMsg to Appl.|Response |
| | |
tg_SendMsg |Queue NSLP msg data |Wait |6)
| |Response |
| | |
Timeout_WaitResponse |(Tx_Query(MAinfo)) || |Wait |
|(Tx_Query(NSLPdata))|| |Response |
|(Tx_Query) | |
| | |
(Timeout_WaitResponse) |Tg_MessageDeliveryError |IDLE |
&&(MaxRetry) | | |
| | |
Tg_ERROR |(Delete MRS) |IDLE |
|IF (MA is used) | |
| ((Delete MA)|| | |
| (Stop using shared MA))| |
|Tg_NetworkNotification | |
| | |
------------------------+-------------------------+-----------+---
---------------------------------
State: Established Downstream MRS
---------------------------------
Condition Action State Note
------------------------+-------------------------+-----------+---
rx_Msg_?mode |IF(CheckPeerInfo) |Established|7)
| Tg_RecvMsg to Appl.|Downstream |
| |MRS |
| | |
tg_SendMsg_?mode |IF(Cmode)&&(MAexist) |Established|9)
| Tx_Msg_Cmode |Downstream |
|IF(Dmode) Tx_Msg_Dmode |MRS |
| | |
((tg_SendMsg)&&(Cmode)&&|Tx_Query(MAinfo) |Wait |10)
(!MAexist))|| |Queue NSLP msg data |Response |
(tg_MA_error)|| | | |
(tg_Path_Change) | | |
| | |
Timeout_refresh |Tx_Query(Refresh) |Established|
| |Downstream |
| |MRS |
| | |
rx_Response(No_MRS |tx_Confirm(RespCookie) |Established|
_installed)|Tx_queued_Msg_Cmode |Downstream |
| |MRS |
| | |
(Timeout_MRSlifetime)|| |(Delete MRS) |IDLE |
(tg_SetStateLifetime(0))| | |
||(Tg_ERROR) | | |
| | |
|Tg_NetworkNotification | |
| | |
(rx_Response_Dmode)|| |IF (MA is used) |Established|5)
(rx_Response_?mode( | ((Delete MA)|| |Downstream |
Mainfo)&&(NewPeer)&&| (Stop using shared MA))|MRS |
(MAexist) |Install MRS | |
|If (RespCookie) | |
| tx_Confirm_?mode(Resp | |
| Cookie)| |
| | |
(rx_Response_?mode( |((Delete MA)|| |Wait MA |*
MAinfo)&&(NewPeer)&&|(Stop using shared MA)) |Establish. |4)
(!MA_exist) |Tg_Establish_MA | |
|(Tx_Confirm_?mode) | |
| | |
| | |
| | |
| | |
| | |
------------------------+-------------------------+-----------+---
----------------------------
State: Wait MA Establishment
----------------------------
Condition Action State Note
------------------------+-------------------------+-----------+---
tg_SendMsg |Queue NSLP msg data |Wait MA |6)
| |Establish. |
| | |
Tg_MA_Established |Install MRS |Established|3)
|(Tx_Confirm_?mode) |Downstream |*
|(Tx_queued_Msg_Cmode) |MRS |**
| | |
Tg_MA_error |Delete MRS |IDLE |
|Tg_NetworkNotification | |
| | |
Tg_ERROR |(Delete MRS) |IDLE |
|IF (MA is used) | |
| ((Delete MA)|| | |
| (Stop using shared MA))| |
|Tg_NetworkNotification | |
| | |
------------------------+-------------------------+-----------+---
NOTE:
*) Response and Confirm messages might be send either in Dmode or
Cmode, before or after MA establishment depending on node's
local 3-way handshake policy and the availability of MAs to be
reused.See draft for details.
**) Depending on the local policy NSLPdata might be send as
payload of Query and Confirm messages. (piggybacking)
- 1)
- Initial request from NSLP are received, which triggers Query messages requesting either D_mode or C_mode. Dependign on local policy of the node, NSLP data might be piggybacked in the Query requesting D_mode.
- 2)
- Response message is received. If C_mode connections must be established and there is no available MA to be reused, MA establishment is initiated and waited to be completed. If D_mode connection is requested or available MA can be reused if C_mode is requested the MRS is established.
- 3)
- New MA is successfully established and MRS, which will use it, is installed.
- 4)
- Path change detected events - local recovery procedure, where D_mode or C_mode with available MA must be established. THIS IS VALID ONLY IF THE NODE IS CROSSOVER NODE
- 5)
- Path change detected events - local recovery procedure, where new MA must be established for requested C_mode connection. THIS IS VALID ONLY IF THE NODE IS CROSSOVER NODE
- 6)
- NSLP data is queued, because downstream peer is not discovered or required MA is still not established.
- 7)
- Received Data messages are checked if their sender matches the installed downstream peer info in the MRS and then processed.
- 8)
- Received Data messages are checked if their sender matches the installed downstream peer info in the MRS and then processed. In WaitResponse state, this event might happen in the process of MA upgrade, when the downstream peer is still not aware of establishment of the new MA.
- 9)
- Depending on the requested transport from NSLP and currently established D_mode or C_mode, NSLP message is sent D_mode if D_mode is requested and C_mode if the features of the used MA covers the required transport ( e.g. used MA is reliable and NSLP request reliable but not secure transport)
- 10)
- External event notifies for Path Change and discovery procedures is restarted. THIS IS VALID ONLY IF THE NODE IS CROSSOVER NODE OR NSLP requests C_mode transport that is not covered by currently used D_mode or MA (case of MA upgrade) and discovery procedure is restared but current downstream peer info is kept in order to be able to receive messages from it during the upgrade process.
| TOC |
-----------
State: IDLE
-----------
Condition Action State Note
------------------------+-------------------------+-----------+---
rx_Query(?) |Tx_Response_Dmode(Resp |Wait |1)
&&(ConfirmRequired) | Cookie)|Confirm |
|IF(NSLPdata) | |
|Tg_RecvMsg(NSLPdata) | |
| to Appl.| |
| | |
rx_Query(?) |Tx_Response_Dmode |Established|2)
&&(!ConfirmRequired) |Install MRS |Upstream |
|IF(NSLPdata) |MRS |
|Tg_RecvMsg(NSLPdata) | |
| to Appl.| |
| | |
rx_Query(MAinfo) |Tx_Response_?mode(Resp |Wait |*
&&(ConfirmRequired) | Cookie, MAinfo)|Confirm |1)
| | |
rx_Query(Mainfo) |Tx_Response_?mode(Resp |Established|*
&&(!ConfirmRequired) | Cookie, MAinfo)|Upstream |2)
|Set WaitConfirm timer |MRS |
|Install MRS | |
| | |
------------------------+-------------------------+-----------+---
-------------------
State: WAIT CONFIRM
-------------------
Condition Action State Note
------------------------+-------------------------+-----------+---
rx_Msg_?mode |Tx_Response(No_MRS_ |Wait |3)
| installed)|Confirm |
| | |
Rx_Confirm_?mode |Install Upstream MRS |Established|*
| |Upstream |6)
| |MRS |
| | |
Timeout_WaitConfirm | |IDLE |
| | |
------------------------+-------------------------+-----------+---
-------------------------------
State: Established Upstream MRS
-------------------------------
Condition Action State Note
------------------------+-------------------------+-----------+---
Rx_Confirm_?mode |Stop WaitConfirm timer |Established|6)
|Install MRS |Upstream |
|Tx_queued_Msg_Cmode |MRS |
| | |
(Timeout_WaitConfirm)&& |(Delete MRS) |IDLE |7)
(!UpstreamPeerInstalled)|IF (MA is used) | |**
| ((Delete MA)|| | |
| (Stop using shared MA))| |
|Tg_NetworkNotification | |
| | |
rx_Msg_?mode |IF(CheckPeerInfo) |Established|8)
| Tg_RecvMsg to Appl.|Upstream |
|ELSE |MRS |
|Tx_Response(No_MRS_ | |
| installed)| |
| | |
tg_SendMsg |IF(WaitConfirm timer set)|Established|9)
| Queue NSLP msg data|Upstream |
|ELSE Tx_Msg_?mode |MRS |
| | |
(Timeout_MRSlifetime)|| |(Delete MRS)&& |IDLE |
(tg_SetStateLifetime(0))|IF (MA is used) | |
| ((Delete MA)|| | |
| (Stop using shared MA))| |
|Tg_NetworkNotification | |
| | |
rx_Query(Refresh) |Refresh MRS |Established|
|Tx_Response(Refresh) |Upstream |
| |MRS |
| | |
(rx_Query(MAinfo))|| |Tx_Response_?mode(Resp |Established|*
((rx_Query)&&(!MAinfo)&&| Cookie, MAinfo)|Upstream |5)
(ConfirmRequired))|Set WaitConfirm timer |MRS |
| | |
(rx_Query)&&(!MAinfo)&& |Install MRS |Established|4)
(!ConfirmRequired) |tx_Response |Upstream |
|IF (MA is used) |MRS |
| ((Delete MA)|| | |
| (Stop using shared MA))| |
|IF(NSLPdata) | |
|Tg_RecvMsg(NSLPdata) | |
| to Appl.| |
| | |
Tg_ERROR |(Delete MRS) |IDLE |
|IF (MA is used) | |
| ((Delete MA)|| | |
| (Stop using shared MA))| |
|Tg_NetworkNotification | |
| | |
------------------------+-------------------------+-----------+---
NOTE:
*) Response and Confirm messages might be send either in Dmode or
Cmode depending on node's local 3-way handshake policy and the
availability of MAs to be reused. See draft for details.
**) Differentiation between WaitConfirm timer expiration of
initial MRS event or MA_upgrade event is based on the presence
of installed peer info in the MRS. If no peer info is installed
this is initial MRS establishment.
- 1)
- Initial Query messages requesting either D_mode or C_mode connection. In both cases, explicit Confirm message is required for MRS installation, based on the local policy. Query requesting D_mode might carry piggybacked NSLP data.
- 2)
- Initial Query messages requesting either D_mode or C_mode connection. In both cases, MRS is installed immediately, based on the local policy. Query requesting D_mode might carry piggybacked NSLP data. In the case of C_mode request, Confirm message is required to confirm the establishment of the used MA.
- 3)
- In case of lost Confirm message, data messages might be received from the upstream node (it is unaware of the lost Confirm message). Response indicating the loss of the Confirm is sent back to the upstream node.
- 4)
- Event of change of the upstream peer (e.g., path change) with request of D_mode and non-paranoid local policy.
- 5)
- Event of request of change of the used connection mode (from D_mode/C_mode to better C_mode), event of change of the upstream peer (e.g., path change) with request for C_mode or D_mode connection and paranoid local policy.
- 6)
- Confirm message is received which causes installation of the complete MRS or just installation of the used MA as a upstream peer info.
- 7)
- Differentiation between WaitConfirm timer expiration of initial MRS event or MA upgrade/change event is based on the presence of installed peer info in the MRS. If no peer info is installed this is initial MRS establishment and installed MRS must be deleted.
- 8)
- Data messages are accepted only if complete MRS is installed, e.g., there is installed upstream peer info. If not then Confirm message is expected and data message will not be accepted but Response indicating the loss of the Confirm is sent back to the upstream node.
- 9)
- NSLP message can't be sent upstream if Confirm message is not received and MA is not installed as upstream peer info. They are queued.
| TOC |
This document does not raise new security considerations. Any security concerns with GIMPS are likely reflected in security related NSIS work already (such as [1] (Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” February 2005.) or [6] (Tschofenig, H. and D. Kroeselberg, “Security Threats for NSIS,” October 2004.)).
For the time being, the state machines described in this document do not consider the security aspect of GMIPS protocol itself. A future versions of this document will add security relevant states and state transitions.
| TOC |
We have left for further version of the document the following issues:
- 1.
- Route change and local repair mechanisms are not covered completely. Currently we provide procedures for local repair in the crossover node. Procedures for identifying the crossover node are left for further study.
- 2.
- The FSM that handles the management of a MA is considered in the document (e.g., tg_Establish_MA, tg_MA_established events), but it is not currently explicitely presented. It is left for future version of the document.
- 3.
- Functionality of, as referred in the document "Lower level pre-processing" (Section 5 (Common Rules)), namely message forwarding, RAO processing, transmission of NSLP data without MRS establishment and providing of the received messages to the appropriate MRS is left for future version of the document.
- 4.
- Currently we use WaitConfirm state in the Responding node FSM, but following the DoS prevention approaches for no state installation in the Responding node before receiving of Confirm message, we consider possible removing of this state. This issue requires further investigations.
| TOC |
Christian Dickmann contributed to refining of the state machine since 01 version.
| TOC |
The authors would like to thank Robert Hancock, Ingo Juchem, Andreas Westermaier, Alexander Zrim, Julien Abeille Youssef Abidi and Bernd Schloer for their insightful comments.
| TOC |
| TOC |
| [1] | Schulzrinne, H., “GIMPS: General Internet Messaging Protocol for Signaling,” draft-ietf-nsis-ntlp-05 (work in progress), February 2005. |
| [2] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997. |
| TOC |
| [3] | Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, “State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator,” draft-ietf-eap-statemachine-06 (work in progress), December 2004 (TXT, PDF). |
| [4] | Institute of Electrical and Electronics Engineers, “DRAFT Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control (Revision),” IEEE 802-1X-REV/D9, January 2004. |
| [5] | Ohba, Y., “State Machines for Protocol for Carrying Authentication for Network Access (PANA),” draft-ohba-pana-statemachine-01 (work in progress), February 2005. |
| [6] | Tschofenig, H. and D. Kroeselberg, “Security Threats for NSIS,” draft-ietf-nsis-threats-06 (work in progress), October 2004. |
| TOC |
| Tseno Tsenov | |
| Siemens | |
| Otto-Hahn-Ring 6 | |
| Munich, Bayern 81739 | |
| Germany | |
| Email: | tseno.tsenov@mytum.de |
| Hannes Tschofenig | |
| Siemens | |
| Otto-Hahn-Ring 6 | |
| Munich, Bayern 81739 | |
| Germany | |
| Email: | Hannes.Tschofenig@siemens.com |
| Xiaoming Fu | |
| University of Goettingen | |
| Telematics Group | |
| Lotzestr. 16-18 | |
| Goettingen 37083 | |
| Germany | |
| Email: | fu@cs.uni-goettingen.de |
| Cedric Aoun | |
| Nortel | |
| France | |
| Email: | cedric.aoun@nortel.com |
| Elwyn B. Davies | |
| Folly Consulting | |
| Soham, Cambs | |
| UK | |
| Phone: | +44 7889 488 335 |
| Email: | elwynd@dial.pipex.com |
| TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright © The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.