Next Steps in Signaling (nsis) T. Sanda (Ed.) Internet-Draft Panasonic Intended status: Informational X. Fu Expires: August 25, 2008 University of Goettingen S. Jeong HUFS J. Manner Univ. of Helsinki H. Tschofenig Nokia Siemens Networks February 22, 2008 Applicability Statement of NSIS Protocols in Mobile Environments draft-ietf-nsis-applicability-mobility-signaling-09.txt Status of this Memo 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 August 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Sanda (Ed.), et al. Expires August 25, 2008 [Page 1] Internet-Draft NSIS Signaling in Mobility February 2008 Abstract Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. Sanda (Ed.), et al. Expires August 25, 2008 [Page 2] Internet-Draft NSIS Signaling in Mobility February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation and Terminology . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Operations for Mobility Support . . . . . . . . . . . . 11 4.1. Basic operation example . . . . . . . . . . . . . . . . . 11 4.2. Localized signaling in mobile scenarios . . . . . . . . . 13 4.2.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Localized State Update . . . . . . . . . . . . . . . . 15 5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 17 5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 17 5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 19 5.3. Interaction with Mobile IP tunneling . . . . . . . . . . . 20 5.3.1. Sender-Initiated Reservation with Mobile IP tunnel . . 20 5.3.2. Receiver-Initiated Reservation with Mobile IP tunnel . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3.3. CRN discovery and State Update with Mobile IP tunneling . . . . . . . . . . . . . . . . . . . . . . 25 6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. NSIS Operation in the multihomed mobile environment . . . 27 6.1.1. Selecting the best interface(s)/CoA(s) . . . . . . . . 27 6.1.2. Differentiation of two types of CRNs . . . . . . . . . 28 6.2. Interworking with other mobility protocols . . . . . . . . 29 6.3. Intermediate node becomes a dead peer . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Changes from -00 version . . . . . . . . . . . . . . . . . 33 9.2. Changes from -01 version . . . . . . . . . . . . . . . . . 34 9.3. Changes from -02 version . . . . . . . . . . . . . . . . . 35 9.4. Changes from -03 version . . . . . . . . . . . . . . . . . 35 9.5. Changes from -04 version . . . . . . . . . . . . . . . . . 36 9.6. Changes from -05 version . . . . . . . . . . . . . . . . . 37 9.7. Changes from -06 version . . . . . . . . . . . . . . . . . 37 9.8. Changes from -07 version . . . . . . . . . . . . . . . . . 38 9.9. Changes from -08 version . . . . . . . . . . . . . . . . . 38 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 12.1. Normative Reference . . . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . . 41 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix B. . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . . . . 47 Sanda (Ed.), et al. Expires August 25, 2008 [Page 3] Internet-Draft NSIS Signaling in Mobility February 2008 1. Introduction Mobility of IP-based nodes incurs route changes, usually at the edge of the network. Route changes may also be caused by reasons other than mobility, such as routing protocol adaptation in response to varying network conditions (load sharing, load balancing, etc), or host multi-homing. Macro mobility also involves the change of the mobile node's IP addresses. Since IP addresses are usually part of flow identifiers, the change of IP addresses implies the change of flow identifiers. Local mobility usually does not cause the change of the global IP addresses, but affects the routing paths within the local access network The NSIS protocol suit consists of two layers: NSIS Transport Layer Protocol (NTLP) and the NSIS Signaling Layer Protocol (NSLP). The General Internet Signaling Transport [1] is the NTLP protocol. GIST is a signaling application independent protocol and transports service- related information between neighboring GIST nodes. Each specific service has its own NSLP protocol; currently there two standardized NSLP protocols, the QoS NSLP [2], and the NAT/Firewall NSLP [3] The goals of this draft are to present the effects of mobility on the NTLP/NSLPs and to provide guides on how such NSIS protocols works in basic mobility scenarios, including support for Mobile IPv4 and Mobile IPv6 scenarios. This draft also briefly introduces interworking with more complex mobility-related scenarios and their issues as further study. Sanda (Ed.), et al. Expires August 25, 2008 [Page 4] Internet-Draft NSIS Signaling in Mobility February 2008 2. Requirements Notation and Terminology 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 RFC2119 [4]. The terminology in this draft is based on [1] and [9]. In addition, the following terms are used. Note that in this draft, a generic route change caused by regular IP routing is referred to as a 'route change', and especially, the route change caused by mobility is referred to as 'mobility' like [9]. (1) Downstream The direction from a data sender towards the data receiver. (2) Upstream The direction from a data receiver towards the data sender. (3) Crossover Node (CRN) A Crossover Node is a node that for a given function is a merging point of two or more paths along which states are installed. In the mobility scenarios, there are two different types of merging points in the network according to the direction of signaling flows followed by data flows as shown in Figure 2 of Section 4.2, where we assume that the MN is the data sender. Upstream CRN (UCRN): the node closest to the data sender from which the state information in the direction from data receiver to data sender begins to diverge after a handover. Downstream CRN (DCRN): the node closest to the data sender from which the state information in the direction from the data sender to the data receiver begins to converge after a handover. In general, the DCRN and the UCRN may be different due to the asymmetric characteristics of routing although the data receiver is the same. (4) State Update State Update is the procedure for the re-establishment of NSIS state on the new path, the teardown of NSIS state on the old path, and the update of NSIS state on the common path due to the mobility. The State Update procedure is used to address mobility for the affected Sanda (Ed.), et al. Expires August 25, 2008 [Page 5] Internet-Draft NSIS Signaling in Mobility February 2008 flows. Upstream State Update: State Update for the upstream signaling flow which is initiated by an upstream signaling initiator. If the MN is a data sender, the State Update is initiated by an NI on the common path (e.g., a CN, an HA, or an MAP). Downstream State Update: State Update for the downstream signaling flow which is triggered by a downstream signaling initiator. If the MN is a data sender, the State Update is triggered by an NI on the new path (e.g., an MN, a mobility agent, or an AR). If a route change happens without any change of the flow identifier, State update on the common path is not required because the flow identifiers do not change. Especially, in mobility scenarios, if the NSIS signaling interacts with local mobility management (LMM) protocols (e.g., HMIPv6), the State Update can be localized within the access network. In this case, setup delay of NSIS signaling can be minimized. Sanda (Ed.), et al. Expires August 25, 2008 [Page 6] Internet-Draft NSIS Signaling in Mobility February 2008 3. Problem Statement IP mobility in its simplest form only includes route changes. This section identifies problems caused by mobility and multihoming, which affect the operations of NSIS protocol suit. We also show how the NSIS protocols cope with the problems identified as below. 1. Change of route and possibly change of the MN IP address Topology changes or network reconfiguration might lead to path changes for data packets sent to or from the MN and can cause an IP address change of the MN. When an IP address changes by mobility, firewall rules, NAT, bindings and QoS reservations become invalid because the established flow identifier refers to a non-existent flow. The impact of an out-dated flow identifier is most servers in the NAT/FW case since the traffic will be blocked, or traffic will be forwarded to the wrong IP address. In the QoS NSLP case, the impact is limited to that the flow experiences best-effort treatment for a limited period of time (until the flow identifier is updated again). NSIS solution: The NSIS suite decouples state and flow identification. A state is stored and referred to by the Session ID (SID). Flows associated with a given NSLP state are defined by the Message Routing Information (MRI). GIST notifies when a routing path associated with a SID changes, and provides a notification to the NSLP. It is then up to the NSLP to update the state information in the network. Thus, the effect is an update to the states, not a full new request. This decoupling effectively solves also a typical problem with certain signaling protocols, where protocol state is identified with flow endpoints, and when a flow endpoint changes, the whole session state becomes invalid. 2. Double state problem Since the state on the old path still remains as it is after re- establishing the state along the new path due to mobility (or route changes), the double reservation problem occurs. Although the state on the old path will be deleted automatically based on the soft state timeout, the refresh timer value may be quite long (e.g., 30s as a default value in RSVP). With the QoS NSLP, this problem might result in the waste of resources and lead to failure of other reservations (due to lack of resources). With the NAT/FW NSLP, it is still possible to re-use this installed state although a mobile node roams to a new location; this means that another host can send data through a firewall without any prior NSIS NAT/FW signaling because of the previous state which is not yet expired. NSIS solution: Removing old state in the network is a functionality Sanda (Ed.), et al. Expires August 25, 2008 [Page 7] Internet-Draft NSIS Signaling in Mobility February 2008 of each NSLP independently. The QoS NSLP solves this through the use of the Reservation Sequence Number (RSN). The RSN makes it possible to identify new updated information related to a resource reservation. A QNE that is CRN for a given reservation is able to tear down an old reservation, and install a new reservation on the new path. More details can be found in the QoS NSLP specification. [WHAT DOES THE NAT/FW DO?] 3. End-to-end signaling and frequency of route changes The change of route and IP addresses in mobile environments is typically much faster and more frequent than traditional route changes caused by node or link failure. This results in a need to update NSLP states at a fast pace. A ping-pong type of handover scenario may happen. Also, the flow identifier (MRI) may change. NSIS solution: If the MRI does not change due to handovers, the NSIS protocols are able to localize the update to only the new path. One of the NSIS nodes on the path is a merging point of the old and new routing paths, and is able to confine the signaling to only the affect path. Thus, no end-to-end signaling is needed. If the MRI changes, end-to-end signaling will happen since all the nodes on the path must be provided with an updated flow identification (MRI); the SID does not change. The ping-pong type of movement is a problem caused by the mobility management. Thus, fixing this is out of scope of the NSIS protocols. 4. Upstream State Update vs. Downstream State Update Since the upstream and downstream paths are likely not to be exactly the same, the upstream and downstream CRNs may not coincide, either. Therefore, the State Update needs to be handled independently for the upstream and the downstream, including the discovery of upstream and downstream CRNs. 5. Identification of the crossover node When a handover at the edge of a network has happened, in the typical case, only some parts of the end-to-end path used by the data packets changes. In this situation, the CRN plays a central role in managing the establishment of the new signaling application state, and removing any useless state. NSIS solution: GIST provides NSLPs with an identifier of the next signaling peer, the SII Handle. When this handle changes, the NSLP knows a routing change has happened. Yet, the NSLP can also figure out if it is also the crossover node for the session. More details can be found in the NSLP specifications. Sanda (Ed.), et al. Expires August 25, 2008 [Page 8] Internet-Draft NSIS Signaling in Mobility February 2008 6. Authorization Issues The procedure of State Update may be initiated by the MN, the CN, or even nodes within the network (e.g., crossover node, MAP in HMIP). This State Update on behalf of the MN raises authorization issues about the entity that is allowed to make these state modifications. NSIS solution: Since NSIS operates on a hop-by-hop basis, any peer can perform state updates. This is possible because a chain-of-trust is expected between NSIS nodes. If this weren't the case, e.g., true resource reservations would not be possible; one misbehaving or compromised node would effectively break everything. Thus, currently the NSIS protocols do not limit the roles of each NSIS signaling peer on a path, and any node can make updates. Yet, some updates are reflected back to the signaling end points, and they can decide whether the signaling actually succeeded, or not. 7. Dead peer and invalid NR problem When the MN is on the path of a signaling exchange, after handover the old AR can not forward NSLP messages any further to the MN. In this case, the old AR's mobility or routing protocol, or even the NSLP may trigger an error message to indicate that the last node fails or is truncated. This error message is forwarded and may mistakenly cause the removal of the state on the existing common path, if the state is not updated before the error message is propagated through the signaling peers. This is called the 'invalid NR problem'. NSIS solution: In general, a QNE should be conservative when it receives an indication for a state removal caused by a change in routing. The QoS NSLP uses retransmissions and the RSN value to cope with the problem - see the QoS NSLP specification for more details. 8. IP-in-IP Encapsulation Mobility protocols may use IP-in-IP encapsulation on the segment of the end-to-end path for routing traffic from the CN to the MN, and vice versa. Encapsulation harms any attempt to identify and filter data traffic belonging to, for example, a QoS reservation. Moreover, encapsulation of data traffic may lead to changes in the routing paths since the source and the destination IP addresses of the inner header differ from those of the outer header. Mobile IP uses tunneling mechanisms to forward data packets among end hosts. Traversing over the tunnel, NSIS signaling messages are transparent on the tunneling path due to the change of flow's addresses. In case of interworking with Mobile IP-tunneling, CRNs can be discovered on the tunneling path. It enables NSIS protocols to perform State Sanda (Ed.), et al. Expires August 25, 2008 [Page 9] Internet-Draft NSIS Signaling in Mobility February 2008 Update procedure over the IP-tunnel. In this case, GIST needs to cope with the change of Message Routing Information (MRI) for the CRN discovery on the tunnel. Also, NSLP signaling needs to determine when to remove the tunneling segment on the signaling path and/or how to tear down the old state via interworking with the IP-tunneling operation. NSIS solution: If the signaling packets are encapsulated it is necessary to perform a separate signaling exchange for the tunneled region. Furthermore, a binding is needed to tie the end-to-end and tunneled session together. The QoS NSLP implements this session binding. In addition to the above-mentioned issues, multihoming and key management related to handovers bring along additional questions. However, these are deemed out of scope of this document. Also, practical implementations typically need various APIs across components within a node. API issues, e.g., APIs from GIST to the various mobility and routing schemes, are also out of scope of this work. The generic GIST API towards NSLP is flexible enough to fulfill most mobility-related needs of the NSLP layer. Sanda (Ed.), et al. Expires August 25, 2008 [Page 10] Internet-Draft NSIS Signaling in Mobility February 2008 4. Basic Operations for Mobility Support In this section, the basic operations of the NSIS protocol suite needed after mobility related route changes are discussed. There may be two possible ways of operations: - Option 1: GIST probes the route change by its periodical internal refreshes, then use NetworkNotification() API primitive to notify NSLPs to update their corresponding state. Here the operation may be incomplete before an end-to-end signaling is accomplished. - Option 2: Upon a handover event (e.g., acquisition of a new IP address in the MN, or update of the binding cache in the HA or the CN, as it will be discussed in Section 5), each NSLP updates its signaling state in the reflected path. For generality this option is preferred as it eventually accomplishes the signaling procedure, no matter whether optimization is encountered. In both options, as the primary task of signaling will be performed in the NSLP layer, and the NSLP operation is of particular importance. In order to illustrate this the following subsection presents an example of QoS NSLP signaling for data traffic from the MN to the CN in the Mobile IPv6 route optimization mode, following the second option approach. Furthermore, optimization of the signaling procedure may be used, to reduce the unnecessary signaling overhead and to minimize the processing. To optimize the signaling, two issues are identified, namely how to discover an appropriate CRN and how to perform the localized signaling (or so-called State Update) according to the direction of data flows. 4.1. Basic operation example The following figure illustrates an example of QoS NSLP signaling in a Mobile IPv6 route optimization case, for the data flow from the MN to the CN, where sender-initiated reservation is used. Once a handover event is detected in the MN, the MN issues a QoS NSLP RESERVE message towards the CN, which carries the unique session ID and other identification information for the session, as well as the reservation requirements. Upon receipt of the RESERVE message, the QoS NSLP nodes (which will be discovered by the underlying NTLP) establish the corresponding QoS NSLP state, and forward the message towards the CN. When there is already an existing NSLP state with the same session ID, the state will be updated. If all the QoS NSLP nodes along the path support the required QoS, the CN in turn responds with a RESPONSE message, to confirm the reservation. Sanda (Ed.), et al. Expires August 25, 2008 [Page 11] Internet-Draft NSIS Signaling in Mobility February 2008 In the bi-directional tunneling case, the only difference is that the RESERVE message should be sent to the HA instead of the CN, and the node which responds with a RESPONSE should be the HA instead of the CN too. More details are discussed in Section 5 Therefore, for the basic operation there is no fundamental difference among different operation modes of Mobile IP, and the main issue of mobility support in NSIS is to trigger NSLP signaling appropriately when a handover event is detected, and the destination of the NSLP signaling shall follow the Mobile IP data path as being path-coupled signaling. In this process, the obsoleted state in the old path is not explicited released. To speed up the process, there is possibility to localize the signaling to speed this process. When the RESERVE message reaches a node, depicted as CRN in this document, where a state is determined for the first time to reflect the same session, the node may issue a NOTIFY message towards the MN's old CoA. The QNE adjacent to MN's old position stops the NOTIFY message, and sends RESERVE message (with Teardown bit set) towards the CN, to release the obsoleted state. This RESERVE with tear message is stopped by the CRN. More details are described in Section 4.2 Sanda (Ed.), et al. Expires August 25, 2008 [Page 12] Internet-Draft NSIS Signaling in Mobility February 2008 MN QNE1 MN QNE2 QNE3 QNE4 CN (CoA1) | (CoA2) | (CRN) | | | | | | | | | | | | | | | | | | |RESERVE | | | | | | |------->| | | | | | | (1) |RESERVE | | | | | | |--------->| | | | | | | (2) |RESERVE | | | | | | |------->| | | | | | | (3) |RESERVE | | | | | | |------->| | | | | NOTIFY| | (4) | | | | |<---------| | | | | | NOTIFY| (9) | | | | |<------------| | | | | | | (10) | | | | | |RESERVE(T) | | | | | |------------>| | | | | | | (11) |RESERVE(T)| | | | | | |--------->| | | | | | | (12) | |RESPONSE| | | | | | |<-------| | | | | |RESPONSE| (5) | | | | | RESPONSE|<-------| | | | |RESPONSE|<---------| (6) | | | | |<------ | (7) | | | | | | (8) | | | | | | | | | | | | | | | | | | Figure 1: Basic operation example 4.2. Localized signaling in mobile scenarios As shown in Figure 2, mobility generally causes signaling path to either converge or diverge depending on the direction of each signaling flow. Sanda (Ed.), et al. Expires August 25, 2008 [Page 13] Internet-Draft NSIS Signaling in Mobility February 2008 Old path +--+ +-----+ original |MN|<------ |OAR | ---------^ address | | |NSLP1| ^ +--+ +-----+ ^ common path | C +-----+ +-----+ +--+ | | |<--|NSLP1|----|CN| | |NSLP2| |NSLP2| | | v New path +-----+ +-----+ +--+ +--+ +-----+ V B A New CoA |MN|<------ |NAR |----------V >>>>>>>>>>>> | | |NSLP1| ^ +--+ +-----+ ^ D ^ >>>>>>>(Binding process)>>>>>>>>>>>>^ <=====(upstream signaling followed by data flows) ===== (a) The topology for upstream NSIS signaling flow due to mobility Old path +--+ +-----+ original |MN|------> |OAR | ----------V | | |NSLP1| address +--+ +-----+ V common path | K +-----+ +-----+ +--+ | | |---|NSLP1|--->|CN| | |NSLP2| |NSLP2| | | v New path +-----+ +-----+ +--+ +--+ +-----+ ^ M N New CoA |MN|------> |NAR |-----------^ >>>>>>>>>>>> | | |NSLP1| ^ +--+ +-----+ ^ L ^ >>>>>>>(Binding process)>>>>>>>>>>>>^ ====(downstream signaling followed by data flows) ======> (b) The topology for downstream NSIS signaling flow due to mobility Figure 2: The topology for NSIS signaling caused by mobility These topological changes caused by mobility make the NSIS state established in the old path useless. It may need to be removed (in the end) as soon as possible. In addition, NSIS state needs to be created along the new path and be updated along the common path. The re-establishment of NSIS signaling may be localized when route Sanda (Ed.), et al. Expires August 25, 2008 [Page 14] Internet-Draft NSIS Signaling in Mobility February 2008 changes (including mobility) occur to minimize the impact on the service and to avoid unnecessary signaling overhead. This localized signaling procedure is referred to as State Update (refer to the terminology section). In mobile environments, for example, the NSLP/ NTLP needs to limit the scope of signaling information only to the affected portion of the signaling path because the signaling path in the wireless access network usually changes only partially. One of the most appropriate nodes to perform the State Update is the CRN where the old and new signaling paths meet. The CRN should be the logical merging point, not physical one. In the end, CRN discovery can be a crucial element to alleviate the double reservation and end-to-end signaling problems identified in Section 3. 4.2.1. CRN Discovery The CRN is discoved at NSLP layer. In case of QoS NSLP, when a RESERVE message with an existing SESSION_ID is received and its Source Identification Information (SII) and MRI are changed, the QNE knows its upstream or downstream peer has changed by handover, for sender-oriented and receiver-oriented reservations, respectively. And realizes it is implicitly the CRN. 4.2.2. Localized State Update Before initiating the State Update, the MN or the CN needs to acquire necessary authentication and authorization for the corresponding state operation. The MN or the CN may also check the availability of resources on the new path. In case of QoS NSLP, the QUERY message can be used to find the availability of resources in the networks (e.g., access networks or core networks). If the resources along the new path are not sufficient, it may be needed to keep the state established previously using multihomed interfaces while blocking incoming new requests. In the downstream State Update, if resources are available, the MN initiates the full RESERVE with a new RSN for state setup toward a CN and also the implicit DCRN discovery is performed by the procedure of signaling as described in Section 4.2.1. The MRI from the DCRN to the CN (i.e., common path) is updated by the RESERVE message. DCRN may also send NOTIFY with "Route change (0x02)" to previous upstream peer. The NOTIFY is forwarded hop-by-hop and reaches to the edge QNE (i.e., QNE1 in Figure 1). After the QNE is aware that the MN as QNI is disappeard, the QNE sends tearing RESERVE towards downstream. When the tearing RESERVE reaches to the DCRN, the DCRN stops forwarding and drops it. Note that, however, it is not necessary for GIST state to be explicitly removed because of the inexpensiveness of Sanda (Ed.), et al. Expires August 25, 2008 [Page 15] Internet-Draft NSIS Signaling in Mobility February 2008 the state maintenance at the GIST layer [1]. Note that, the sender- initiated approach leads to faster setup than the receiver-initiated approach as in RSVP [5]. In the scenario of an upstream State Update, there are two possible methods for state update. One is the CN (or a HA/ a GFA/ a MAP) sends the refreshing RESERVE message toward the MN to perform State Update by receiving trigger (e.g., MIP binding update). UCRN is discovered implicitly by the CN-initiated signaling along the common path as described in Section 4.2.1. When the refreshing RESERVE reaches to the adjacent QNE of UCRN, the QNE sends back a RESPONSE saying "full QSPEC required". Then the UCRN sends the full RESERVE towards the MN to set up a new reservation. The UCRN may also send tearing RESERVE to previous downstream peer. The tearing RESERVE is forwarded hop-by-hop and reaches to the edge QNE. After the QNE is aware that the MN as QNI is disappeard, the QNE drops the tearing peer. The other is, if GIST hop is already established on the new path (e.g. by QUERY from the CN ((or a HA/ a GFA/ a MAP))) when MN gets a hint from GIST that routing has changed, the MN sends a NOTIFY towards upstream saying "Route Change" 0x02. When the NOTIFY hits UCRN, the UCRN is aware that the NOTIFY is for a known session comes from a new SII-Handle. Then the UCRN sends a full RESERVE with a new RSN and an RII towards the MN. By receiving full RESERVE, the MN replies RESPONSE. The UCRN may also send tearing RESERVE to previous downstream peer. The tearing RESERVE is forwarded hop-by-hop and reaches to the edge QNE. After the QNE is aware that the MN as QNI is disappeard, the QNE drops the tearing peer. The State Update on the common path to reflect the changed MRI brings issues on the end-to-end signaling addressed in Section 3. Although the State Update over the common path does not give rise to re- processing of AAA and admission control, it may lead to the increased signaling overhead and latency. One of the goals of the State Update is to avoid the double reservation on the common path as described in Section 3. The double reservation problem on the common path can be solved by establishing a signaling association using a unique SID and by updating packet classifier/flow identifier. In this case, even though the flows on the common path have different flow dentifiers, it keeps same NSLP state. Sanda (Ed.), et al. Expires August 25, 2008 [Page 16] Internet-Draft NSIS Signaling in Mobility February 2008 5. Interaction with Mobile IPv4/v6 In Mobile IP scenario, there are two types of data routings, one is triangular routing with tunneling section, and the other is optimized routing which is direct routing between an MN and a CN. This section analyzes NSIS operation with these data routes. 5.1. Interaction with Mobile IPv4 In Mobile IPv4 [6], the data flows are forwarded based on triangular routing, and an MN retains a new CoA from the FA (or an external method such as DHCP) in the visited access network. When the MN acts as a data sender, the data and signaling flows sent from the MN are directly transferred to the CN not necessarily through the HA or indirectly through the HA using the reverse routing. On the other hand, when the MN act as a data receiver, the data and signaling flows sent from the CN are routed through the IP tunneling between the HA and the FA (or the HA and the MN in case of the Co-located CoA). With this approach, routing is dependent on the HA, and therefore the NSIS protocols interact with the IP tunneling procedure of Mobile IP for signaling. The Figure 3 (a) to (e) show the NSIS signaling flows depending on the direction of the data flows and the routing methods. Sanda (Ed.), et al. Expires August 25, 2008 [Page 17] Internet-Draft NSIS Signaling in Mobility February 2008 MN FA (or FL) CN | | | | IPv4-based Standard IP routing | |------------ |--------------------------------->| | | | (a) MIPv4: MN-->CN, no reverse tunnel MN FA HA CN | IPv4 (normal) | | | |--------------->| IPv4(tunnel) | | | |--------------->| IPv4 (normal)| | | |------------->| (b) MIPv4: MN-->CN, the reverse tunnel with FA CoA MN (FL) HA CN | | | | | IPv4(tunnel) | | |------------------------------->|IPv4 (normal) | | | |-------------->| (c) MIPv4: MN-->CN, the reverse tunnel with Co-located CoA CN HA FA MN |IPv4 (normal) | | | |-------------->| | | | | MIPv4 (tunnel) | | | |---------------->| IPv4 (normal)| | | |------------->| (d) MIPv4: CN-->MN, Foreign agent Care-of-address CN HA (FL) MN |IPv4(normal ) | | | |-------------->| | | | | MIPv4 (tunnel) | | | |------------------------------->| | | | | (e) MIPv4: CN-->MN with Co-located Care-of-address Figure 3: NSIS signaling flows under different Mobile IPv4 scenarios When an MN (as a signaling sender) arrives at a new FA and the corresponding binding process is completed (Figure 3 (a), (b) and Sanda (Ed.), et al. Expires August 25, 2008 [Page 18] Internet-Draft NSIS Signaling in Mobility February 2008 (c)), the MN performs the CRN discovery (DCRN) and the State Update toward the CN (as described in Section 4) to establish the NSIS state along the new path between the MN and the CN. In case reverse tunnel is not used (Figure 3 (a)), a new NSIS state is established on direct path from the MN to the CN. If the reverse tunnel and FA CoA are used (Figure 3 (b)), a new NSIS state is established along a tunneling path from the FA to the HA separately from end-to-end path. CRN discovery and State Update in tunneling path is also separately performed if necessary. If the reverse tunnel and co-located CoA are used (Figure 3 (c)) the NSIS signaling for the DCRN discovery and the State Update is the same as the case of using FA CoA above except for the use of the reverse tunneling path from the MN to the HA. That is, in this case, one of tunnel end points is the MN, not the FA. When an MN (as a signaling receiver) arrives at a new FA and the corresponding binding process is completed (Figure 3 (d) and (e)), the MN sends NOFITY message to the signaling sender, i.e., the CN. In case FA CoA is used (Figure 3 (d)), the CN initiates a NSIS signaling to update an existing state between the CN and the HA, and afterwards the NSIS signaling messages are forwarded to the FA and reaches to the MN. A new NSIS state is established along the tunneling path from the HA to the FA separately from end-to-end path. During this operation, a UCRN is discovered on the tunneling path, and a new flow identifier for the State Update on the tunnel may need to be created. CRN discovery and State Update in tunneling path is also separately performed if necessary. In case collocated CoA is used (Figure 3 (d)) the NSIS signaling for the UCRN discovery and the State Update is also the same as the case of using FA CoA above except for the end point of tunneling path from the HA to the MN. Note that Mobile IPv4 optionally supports route optimization. In the case route optimization is supported, the signaling operation will be the same as Mobile IPv6 route optimization. 5.2. Interaction with Mobile IPv6 Unlike Mobile IPv4, with Mobile IPv6 [7], the FA is not required on the data path. If an MN moves to visited network, a CoA at the network is allocated like co-located CoA in Mobile IPv4. In addition, the route optimization process between the MN and CN can be used to avoid the triangular routing in the Mobile IPv4 scenarios. If the use of route optimization is not mandatory, data flow routing and NSIS signaling procedures (including the CRN discovery and the State Update) will be similar to the case of using the Mobile IPv4 with co-located CoA. However, if Route Optimization is used, signaling messages are sent directly from the MN to the CN, or from the CN to the MN. Therefore, route change procedures described in Sanda (Ed.), et al. Expires August 25, 2008 [Page 19] Internet-Draft NSIS Signaling in Mobility February 2008 Section 4 are applicable to this case. 5.3. Interaction with Mobile IP tunneling In this section, we assume that MN acts as a signaling sender and CN acts as a signaling receiver in interworking between Mobile IP and NSIS signaling. Scenarios for interaction with Mobile IP tunneling vary depending on: - Whether a tunneling entry point (Tentry) is an MN or other node. In case Mobile IPv4 co-located CoA or Mobile IPv6, Tentry is an MN. In case Mobile IPv4 FA CoA case, Tentry is a FA. In both case, a HA is tunneling exit point (Texit). - Whether the mode of QoS-NSLP signaling is sender-initiated or receiver initiated. - Whether the signaling mode over tunnel is sequential mode or parallel mode. In sequential mode, end-to-end signaling pauses when it is waiting for results of tunnel signaling, and resumes upon receipt of the tunnel signaling outcome. In parallel mode, end-to-end signaling continues outside the tunnel while tunnel signaling is still in process and its outcome is unknown [8]. The following subsection describes sender-initiated and receiver- initiated reservation with Mobile IP tunneling and CRN discovery and State Update with Mobile IP tunneling. 5.3.1. Sender-Initiated Reservation with Mobile IP tunnel The following scenario assumes that a FA is a Tentry. However the procedure is the same for the case an MN is a Tently if it is considered that the MN and the FA are the same node. - When an MN moves into a new network attachment point, QoS- NSLP in the MN initiates RESERVE (end-to-end) message to start the State Update procedure. The GIST below the QoS-NSLP adds GIST header and then sends the encapsulated RESERVE message to peer GIST node with corresponding QoS-NSLP for DCRN discovery. In this case, the peer GIST node is a FA if the FA is an NSIS-aware node. The FA is one of the endpoints of Mobile IP tunneling: Tentry. In case of interaction with tunnel signaling originated from the FA, there can be two scenarios depending on whether NSIS signaling interacts with the Mobile IP tunneling. The first scenario is that the NSIS signaling is discerned on the tunneling path between the FA and corresponding HA, and then the tunneling path becomes an NSIS-aware cloud. The second one is otherwise, and here the Sanda (Ed.), et al. Expires August 25, 2008 [Page 20] Internet-Draft NSIS Signaling in Mobility February 2008 tunneling path is transparent as a logical link to NSIS signaling [8]. - In the NSIS-aware tunneling scenarios, as shown in Figure 4 and Figure 5, upon receiving the RESERVE message from the MN, the QoS- NSLP of FA explicitly creates a new RESERVE-t (tunnel) message, which keeps the existing (end-to-end) Session ID and includes a new (tunneling) Flow ID different from the (end-to-end) flow ID, to distinguish the NSIS signaling messages over the Mobile IPv4 tunneling path. The RESERVE-t message is forwarded toward HA, another end point of Mobile IPv4 tunneling. Also, after receiving the RESERVE-t message from the FA, the HA should decide whether it needs to initiate a RESPONSE-t (tunnel) message toward FA for responding to the RESERVE-t message, or make the RESPONSE-t message wait until a RSESPONSE message, which is created to react the RESERVE message, arrives from the CN. - In this procedure of NSIS-tunnel signaling, again, two categories of tunnel signaling mode are taken into consideration, i.e., either sequential or parallel mode. - Provided that the tunnel signaling mode is sequential as shown in Figure 4, the RESERVE signaling toward the HA resumes after confirming completeness of NSIS tunnel signaling through the RESERVE-t and the RESPONSE-t messages. Arriving at HA, the RESERVE message is forwarded to CN to update or refresh the existing NSIS states (QoS-NSLP and GIST) on the common path. The CN initiates a RESPONSE message, responding to the RESERVE message, toward the HA as its destination. The HA forwards the RESPONSE message to the FA after encapsulating the message. Finally, the RESPONSE message is sent to MN after being decapsulated at the FA. Note that both end-to-end signaling messages, the RESPONSE and the RESERVE messages, are not discernible on the tunneling path, like a logical link, and those messages just play a role of NSIS signaling for establishing end- to-end state. - Provided that the tunnel signaling mode is parallel as shown in Figure 5, upon receiving the RESERVE message from the MN, the FA forwards it to the HA at the drop of a hat. Also, arriving at the HA from the CN, the RESPONSE message is again forwarded from the HA to the FA regardless of the delivery of RESPONSE-t message. Since in this parallel mode the end-to-end signaling messages do not reconcile with both NSIS-tunnel signaling messages, the RESERVE-t and RESPONSE-t messages, the tunneling path operates like a logical link and thus NON-QoS-HOP flag is set within the RESERVE message although NSIS-tunnel signaling messages are available on the tunnel path. Sanda (Ed.), et al. Expires August 25, 2008 [Page 21] Internet-Draft NSIS Signaling in Mobility February 2008 MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver) | | | | | | RESERVE | | | | +--------->| | | | | |RESERVE-t | | | | +=========>| | | | | |RESERVE-t | | | | +=========>| | | | |RESPONSE-t| | | | |<=========+ | | |RESPONSE-t| | | | |<=========+ | | | | RESERVE | | | +-------------------->| | | | | | RESERVE | | | | +--------->| | | | | RESPONSE | | | | |<---------+ | | RESPONSE | | | |<--------------------+ | | RESPONSE | | | | |<---------+ | | | | | | | | Figure 4: Sender-Initiated QoS-NSLP over Tunnel - Sequential Mode Sanda (Ed.), et al. Expires August 25, 2008 [Page 22] Internet-Draft NSIS Signaling in Mobility February 2008 MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver) | | | | | | RESERVE | | | | +--------->| | | | | |RESERVE-t | | | | +=========>| | | | | |RESERVE-t | | | | +=========>| | | | RESERVE | | | +-------------------->| | | | | | RESERVE | | | | +--------->| | | | | RESPONSE | | | | |<---------+ | | |RESPONSE-t| | | | |<=========+ | | |RESPONSE-t| | | | |<=========+ | | | | RESPONSE | | | |<--------------------+ | | RESPONSE | | | | |<---------+ | | | | | | | | Figure 5: Sender-Initiated QoS NSLP over Tunnel - Parallel Mode 5.3.2. Receiver-Initiated Reservation with Mobile IP tunnel Figure 6 and Figure 7 show examples of receiver-initiated operation with Mobile IP tunnel for Sequential and Parallel modes, respectively. Basic Operation is the same as sender-initiated case. Sanda (Ed.), et al. Expires August 25, 2008 [Page 23] Internet-Draft NSIS Signaling in Mobility February 2008 MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver) | | | | | |QUERY | | | | +--------->| QUERY | | | +-------------------->| QUERY | | | | +--------->| | | | | RESERVE | | | RESERVE |<---------+ | |<--------------------+ | | | QUERY-t | | | | +=========>| QUERY-t | | | | +=========>| | | | |RESERVE-t | | | |RESERVE-t |<=========+ | | |<=========+ | | | |RESPONSE-t| | | | RESERVE +=========>|RESPONSE-t| | |<---------| +=========>| | | RESPONSE | | | | +--------->| RESPONSE | | | +-------------------->| RESPONSE | | | | +--------->| | | | | | Figure 6: Receiver-Initiated QoS NSLP over Tunnel - Sequential Mode Sanda (Ed.), et al. Expires August 25, 2008 [Page 24] Internet-Draft NSIS Signaling in Mobility February 2008 MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver) | | | | | |QUERY | | | | +--------->| QUERY | | | +-------------------->| QUERY | | | | +--------->| | | | | RESERVE | | | RESERVE |<---------+ | RESERVE |<--------------------+ | |<---------+ | | | | | QUERY-t | | | | +=========>| QUERY-t | | | | +=========>| | | | |RESERVE-t | | | |RESERVE-t |<=========+ | | |<=========+ | | | |RESPONSE-t| | | | +=========>|RESPONSE-t| | | | +=========>| | | RESPONSE | | | | +--------->| RESPONSE | | | +-------------------->| RESPONSE | | | | +--------->| | | | | | Figure 7: Receiver-Initiated QoS NSLP over Tunnel - Parallel Mode 5.3.3. CRN discovery and State Update with Mobile IP tunneling Interaction with Mobile IP tunneling scenario can define two types of CRNs, i.e., a CRN on end-to-end path and a CRN on tunneling path. CRN discovery and State Update for these two paths are operated independently. CRN discovery for end-to-end path is initiated by the MN by sending RESERVE (sender-initiated case) or QUERY (receiver-initiated case) message. As MN uses HoA as source address even after handover, a CRN is found by normal route change process (i.e., the same SID and FID, but different SII handle). If a HA is QoS-NSLP aware, the HA is found as the CRN. The CRN initiate tearing process on the old path as described in [2] CRN discovery for tunneling path is initiated by Tentry by sending RESERVE-t (sender-initiated case) or QUERY-t (receiver-initiated case) message. The route change procedures described in Section 4 Sanda (Ed.), et al. Expires August 25, 2008 [Page 25] Internet-Draft NSIS Signaling in Mobility February 2008 are applicable to this case. Sanda (Ed.), et al. Expires August 25, 2008 [Page 26] Internet-Draft NSIS Signaling in Mobility February 2008 6. Further Studies This section introduces potential issues and possible approaches for complicated scenarios in the mobile environment, i.e., peer failure scenarios, multihomed scenarios, and interworking with other mobility protocols. Topics in this section are out-of-scope of this document, and detailed operations are not discussed. All topics are for future studies. 6.1. NSIS Operation in the multihomed mobile environment In multihomed mobile environments, multiple interfaces and addresses (i.e., CoAs and HoAs) are available. This case, two major issues can be considered. One is how to select or acquire the most appropriate interface(s) and/or address(es) from end-to-end QoS point of view. The other is, when multiple paths are simultaneously used for load- balancing purpose, how to differentiate and manage two types of CRNs, i.e., CRN between two on-going Paths (LB-CRN: Load Balancing CRN) and CRN between the old and new paths caused by MN's handover (HO-CRN: Handover CRN). This section introduces possible approaches for these issues. 6.1.1. Selecting the best interface(s)/CoA(s) In MIPv6 route optimization case, if multiple CoAs registration is provided [10], the contents of QUERYs sent by candidate CoAs can be used to select the best interface(s)/CoA(s). Assume that an MN is a data sender and has multiple interfaces. Now the MN moves to a new location and acquires CoA(s) for multiple interfaces. After the MN performs the BU/BA procedure, it sends QUERY messages toward the CN through the interface(s) associated with the CoA(s). On receiving the QUERY messages, the CN or Gateway, determines the best (primary) CoA(s) by checking 'QoS available' field in the QUERY messages. Then a RESERVE message is sent toward the MN to reserve resources along the path the primary CoA takes. If the reservation is not successful, the CN transmits another RESERVE message using the CoA with the next highest priority. The CRN may initiate a teardown (RESERVE with the TEAR flag set) message toward old access router (OAR) to release the reserved resources on the old path. In case of sender-initiated reservation, a similar approach is possible. That is, the QUERY and RESERVE messages are initiated by an MN, and the MN selects the Primary CoA based on the information delivered by the QUERY message. Sanda (Ed.), et al. Expires August 25, 2008 [Page 27] Internet-Draft NSIS Signaling in Mobility February 2008 |--Handover-->| MN OAR AR1 AR2 AR3 CRN CRN CRN CN (OAR/AR1)(OAR/AR2)(OAR/AR3) | | | | | | | | | |---QUERY(1)->|-------------------->|---------------------->| | | | | | | | | | |---QUERY(2)-------->|--------------------->|-------------->| | | | | | | | | | |---QUERY(3)--------------->|---------------------->|------>| | | | | | | | | | | | | | | | | | Primary CoA | | | | | | | | Selection(4) | | | | | | | | | | | | | | | |<--RESERVE(5)--| | | | |<------RESERVE(6)-----| (Flow ID | | | | | (Actual reservation) | Update) | |<----RESERVE(7)-----| | | | | | | | | | | | | | | | |<-----------teardown(8)-------------| | | | | | | | | | | | | | | | Multimedia Traffic | | | |<=================->|<===================->|<=============>| | | | | | | | | | Receiver-initiated reservation in the multihomed environment 6.1.2. Differentiation of two types of CRNs When multiple interfaces of the MN are simultaneously used for load- balancing purpose, a possible approach for distinguishing LB-CRN and HO-CRN will introduce an identifier to determine the relationship between interfaces and paths. An MN uses interface 1 and interface 2 for the same session, where the paths (say path 1 and path 2) have the same SID but different FIDs as shown in (a) of Figure 9. Now one of the interfaces of MN performs a handover and obtains a new CoA, the MN will try to establish a new path (say Path 3) with the new FID, as shown in (b) of Figure 9. In this case the CRN between path 2 and path 3 cannot determine if it is LB-CRN or HO-CRN since for both cases, SID is the same but FIDs are different. Hence the CRN will not know if State Update is required. One possible solution to solve this issue will introduce path classification identifier which shows the relationship between interfaces and paths. For example, signaling messages and QNEs belong to paths from interface 1 and interface 2 carry the identifier '00' and '02', respectively. By having this identifier, Sanda (Ed.), et al. Expires August 25, 2008 [Page 28] Internet-Draft NSIS Signaling in Mobility February 2008 the CRN between path 2 and path 3 will be able to determine whether it is LB-CRN or HO-CRN. For example, if path 3 carries '00', the CRN is LB-CRN, and if '01', the CRN is HO-CRN. +--+ Path 1 +---+ +--+ | |IF1 <-----------------|LB | common path | | |MN| |CRN|-------------|CN| | | Path 2 | | | | | |IF2 <-----------------| | | | | | +---+ +--+ | | +--+ (a) NSIS Path classification in multihomed environments +--+ Path 1 +---+ +--+ | |IF1 <-----------------|?? | common path | | |MN| |CRN|-------------|CN| | | Path 2 -| | | | | |IF2 <--- +------+ | | | | | | | \_|??-CRN|--v +---+ +--+ | | / +------+ +--+IF? <--- Path 3 (b) NSIS Path classification after handover Figure 9: The topology for NSIS signaling in multihomed mobile environments 6.2. Interworking with other mobility protocols Unlike the generic route changes, in mobility scenarios, the end-to- end signaling problem by the State Update gives rise to the degradation of network performance, e.g., increased signaling overhead, service blackout, and so on. To reduce signaling latency in the Mobile IP-based scenarios, the NSIS protocol suite may need to interwork with localized mobility management (LMM). If the GIST/NSLP (QoS-NSLP or NAT/FW-NSLP) protocols interact with Hierarchical Mobile IPv6 and the CRN is discovered between an MN and an MAP, the State Update can be localized by address mapping. However, how the State Update is performed with scoped signaling messages within the access network under the MAP is for future study. Sanda (Ed.), et al. Expires August 25, 2008 [Page 29] Internet-Draft NSIS Signaling in Mobility February 2008 In the inter-domain handover, a possible way to mitigate the latency penalty is to use the multi-homed MN. It is also possible to allow the NSIS protocols to interact with mobility protocols such as Seamoby protocols (e.g., CARD [RFC4066] and CXTP [RFC4067]) and FMIP. Another scenario is to use peering agreement which allows aggregation authorization to be performed for aggregate reservation on an inter- domain link without authorizing each individual session. How these approaches can be used in NSIS signaling is for further study. 6.3. Intermediate node becomes a dead peer The failure of a (potential) NSIS CRN may result in incomplete state re-establishment on the new path and incomplete teardown on the old path after handover. In this case, a new CRN should be re-discovered immediately by the CRN discovery procedure. The failure of an AR may make the interactions with Seamoby protocols (such as CARD and CXTP) impossible. In this case, the neighboring peer closest to the dead AR may need to interact with such protocols. A more detailed analysis of interactions with Seamoby protocols is left for future work. In Mobile IP-based scenarios, the failures of NSIS functions at an FA and an HA may result in incomplete interaction with IP-tunneling. In this case, recovery for NSIS functions needs to be performed immediately. In addtion, a more detailed analysis of interactions with IP-tunneling is left for future work. Sanda (Ed.), et al. Expires August 25, 2008 [Page 30] Internet-Draft NSIS Signaling in Mobility February 2008 7. Security Considerations This document does not introduce new security concerns. The security considerations pertaining to the standard NSIS protocol specifications [gist, qos-nslp, natfw-nslp] remain relevant. When deployed in service provider networks, it is mandatory to ensure that only authorized entities are permitted to initiate re-establishment and removal of NSIS states in mobile environments, including the use of NSIS proxies. Sanda (Ed.), et al. Expires August 25, 2008 [Page 31] Internet-Draft NSIS Signaling in Mobility February 2008 8. Open Issues 1. MIP Interaction Part (Section 5) - This section should illustrate how Tunnel I-D is applicable to MIP cases. Discussion: How does this section should be cleaned up? Sanda (Ed.), et al. Expires August 25, 2008 [Page 32] Internet-Draft NSIS Signaling in Mobility February 2008 9. Change History 9.1. Changes from -00 version The major change made to the initial (-00) version of the draft is to re-arrange the issues addressed in the draft in order to clearly identify general issues caused by mobility itself and NSIS protocols- specific issues. The generic route changes-related text in Section 4 was moved into Appendix to make this draft more mobility-specific. Specifically, the following changes have been made: 1. Removed the terminologies, 'uplink' and 'downlink' in Section 2. 2. Removed the terminology, 'local repair' in Sections 2 and 4. 3. Re-arranged all problems in Section 3 by merging the 'mobility- related issues with NSIS protocols' section and the 'problem statement and general considerations' section. 4. Removed the general considerations section in Section 3. 5. Modified the problem statement section and moved it into the general problem section in Section 3.1. 6. Added more problems including 'Identification of the crossover node', 'Key exchanges', and 'AA-related Issues' to Section 3.1 7. Added the 'Multihoming-related issues' to Section 3.2.4 8. Removed the issues on 'how to immediately delete the state on the old path' in Section 3.2. 9. Moved the generic route changes-related text in Section 4.1 into Appendix. 10. Removed the figure describing "NSIS signaling topology for downstream signaling flow after the route changes in the middle of the network" in Figure 2. 11. Added 'NSLP_IDs' to each node in Figure 1. 12. Removed the 'use cases of identifiers' section, and instead, added the 'support for ping-pong type handover' section to Section5. 13. Added this change history. Sanda (Ed.), et al. Expires August 25, 2008 [Page 33] Internet-Draft NSIS Signaling in Mobility February 2008 9.2. Changes from -01 version Version -02 includes mainly a number of clarifications on the issues raised in this draft and more details in some specific areas. Specifically, the following changes have been made: 1. Defined the terminologies, 'route change' and 'mobility' in Section 2. 2. Clarified the terminology, 'Crossover node (CRN)' in Section 2. 3. Removed the terminology, 'mobility CRN' in Section 2. 4. The issue, 'Priority of signaling messages' in Section 3.2.2 was closed, and thus removed it. 5. Clarified the issue, 'CRN discovery and State Update on the IP- tunneling path in Section 3.2.4. 6. Added the pros and cons of two mechanisms on CRN discovery dependent on NSIS layers to Section 4.2.1. 7. Clarified the identifier, NSLP_Br_ID for CRN discovery in Section 4.2.2. 8. Added the scenario on interaction between NSIS and Mobile IP to Section 5.1. 9. Clarified interaction issues with IP-tunneling according to reservation initiation type (receiver-initiated or sender- initiated) in Mobile IPv4-based scenarios and added those to Section 5.1.1.1. 10. 1Clarified interaction issues between NSIS protocols and IP- tunneling in Mobile IPv6 and added those to Section 5.1.1.2. 11. Clarified the multihoming-related issues in Section 5.2. 12. Added the issues on usage of 'hint' information to trigger NSIS signaling in mobility to Section 5.5. 13. Identified the dead peer-related issues in Mobile IP-based scenario in Section 5.5. Sanda (Ed.), et al. Expires August 25, 2008 [Page 34] Internet-Draft NSIS Signaling in Mobility February 2008 9.3. Changes from -02 version In version -03, tunneling-related and multihoming-related scenarios were newly added in Sections 5.1.3 and 5.2, respectively. Also, the terminology, 'Path Update' is changed into 'State Update' in Section 3.2.4. 9.4. Changes from -03 version Version -04 includes mainly a number of clarifications on the issues raised in this draft and more details in some specific areas. Specifically, the following changes have been made: 1. The issue, 'Peering agreement issue' in Section 3.2.2 was closed, and thus removed it. 2. Clarified the issue, 'Interfaces between Mobile IP and NSIS protocols' in Section 3.2.1. 3. Clarified the issue, 'Authorization-related issues with teardown' in Section 3.2.2. 4. Clarified the issue, 'Dead peer discovery' in Section 3.2.2. 5. Clarified the issue, 'Invalid NR problem' in Section 3.2.2. 6. Clarified the issue, 'CRN discovery and State Update on the IP- tunneling path' in Section 3.2.4. 7. Clarified the issue, 'Multihoming-related issues' in Section 3.2.4. 8. Changed Figure 1 (a) into (b) in Section 4.1. 9. Changed Figure 1 (b) into (a) in Section 4.1. 10. Clarified the identifier, NSLP_Br_ID for CRN discovery in Section 4.2.2. 11. Clarified the identifier, Mobility identifier for CRN discovery in Section 4.2.2. 12. Added the text on 'CRN_DISCOVERY flag bit' in Section 4.2.3, and clarified the role of 'CD flag bit' in Section 4.3.1. 13. Clarified the issues on 'interaction with Mobile IP tunneling' and added those to Section 5.1.4. Sanda (Ed.), et al. Expires August 25, 2008 [Page 35] Internet-Draft NSIS Signaling in Mobility February 2008 14. Clarified the issues on 'load balancing in multihomed mobile environments' and added those to Section 5.2.5. 15. Changed Problems of the heading name in Section 3.2 into Challenges. 9.5. Changes from -04 version Version -05 includes mainly a number of clarifications on the issues raised in this draft and more details in some specific areas. Specifically, the following changes have been made: 1. 'Explicit routes' in Section 3.1 (3) was removed. 2. Clarified the problem, 'Double reservation problem' in Section 3.1 (7). 3. Clarified the issue, 'CRN discovery-related issues' in Section 3.2.4 (1). 4. Clarified the issue, 'Issues on API between NTLP and NSLP' in Section 3.2.4 (3). 5. Clarified the issue, 'approaches for CRN discovery' in Section 4.2.1. 6. Changed NSLP_Br_ID (of identifiers for CRN discovery) into State_Br_ID in Section 4.2.2 for clarification. 7. Clarified the issue, 'double reservation problem on the common path' in Section 4.3.1. 8. Clarified the issue, 'Interfaces between Mobile IP and NSIS' in Section 5.1.1. 9. Removed the sencond paragraph on the issue, 'Explicit routes' in Section 4.1. 10. Clarified the issue, 'refresh timer value in mobility scenarios' in Section 5.3. 11. Removed the third paragraph on the issue, 'usage of Reservation Sequence Number (RSN) to support ping-pong type hanover' in Section 5.4. 12. Clarified the issues on 'peer failure' in Section 5.5. Sanda (Ed.), et al. Expires August 25, 2008 [Page 36] Internet-Draft NSIS Signaling in Mobility February 2008 13. Removed Figure 3 'Sender- vs. Receiver-initiated reservation' in Section 4.3.1. 9.6. Changes from -05 version In Version -06, contents of this draft were re-selected and re- structured: 1. Section 4 and 5 of -05 were divided into two parts: 1. 'Main' part, which is focusing on examples and describing how mobility is handled by the NSIS protocols. Topics here will be route change handling and NSIS interwork with MIP v4/v6 (Section 4 and Section 5 in -06) 2. 'Further Study' part, which introduces summary of potential issues and possible approaches for other topics. These topics are out-of-scope for discussing details (Section 6 in -06) 2. Specific parameters and terms were removed from 'Main' part 3. Showing similar detailed operations were avoided in 'Interaction with MIP tunneling section (Section 5.3)' 4. In Further Study section Section 6: 1. Detailed operations were removed 2. Ping-pong issue was removed 5. Problem Statement (Section 3) was cleaned up 9.7. Changes from -06 version Changes in Version -07 are: 1. 'Invalid NR problem' are moved from Further Study section 2. Figure 7 (Receiver-Initiated QoS NSLP over Tunnel -Parallel Mode) are changed 3. Terminologies 'NSLP CRN', 'NTLP CRN' 'NSIS CRN' 'Divergent- convergent UCRN' and 'Divergent-convergent DCRN' are removed from Terminology section. 4. 'Open Issues' section is added Sanda (Ed.), et al. Expires August 25, 2008 [Page 37] Internet-Draft NSIS Signaling in Mobility February 2008 9.8. Changes from -07 version Changes in Version -08 are: 1. Figure 1 was updated (NOTIFY message from CRN is added) 2. Section 4.2.1 (CRN discovery) was updated to be synchronized with QoS-NSLP draft 3. Title of Section 4.2.2 was changed from "State setup and update" to "Localized State Update" 4. Section 4.2.2 (Localized State Update) was updated to be synchronized with QoS-NSLP draft 5. Section 4.2.3 (State teardown) was deleted because the issues was already solved 6. Title of Section 4.2.3 was changed to "State teardown consideration" 9.9. Changes from -08 version Changes in Version -09 are: 1. Security Consideration Section (Section 7) was cleaned up. 2. Security Consideration issue was removed from Open Issue section (Section 8). 3. NAT traversal issues were removed from Open Issue section (Section 8). Sanda (Ed.), et al. Expires August 25, 2008 [Page 38] Internet-Draft NSIS Signaling in Mobility February 2008 10. Contributors Sung-Hyuck Lee was the first editor of the draft. Since version 06 of the draft, Takako Sanda has taken the editorship. Many individuals have contributed to this draft. Since it was not possible to list them all in the authors section, this section was created to have a sincere respect for other authors, Paulo Mendes, Robert Hancock, Roland Bless and Shivanajay Marwaha. Separating authors into two groups was done without treating any one of them better (or worse) than others. Sanda (Ed.), et al. Expires August 25, 2008 [Page 39] Internet-Draft NSIS Signaling in Mobility February 2008 11. Acknowledgements The authors would like to thank Byoung-Joon Lee, Charles Q. Shen, Cornelia Kappler, Henning Schulzrinne, and Jongho Bang for significant contributions in four earlier drafts and the previous draft. The authors would also like to thank Robert Hancock, Andrew Mcdonald, John Loughney, Rudiger Geib, Cheng Hong, Elena Scialpi, and Pratic Bose for their useful comments and suggestions. Sanda (Ed.), et al. Expires August 25, 2008 [Page 40] Internet-Draft NSIS Signaling in Mobility February 2008 12. References 12.1. Normative Reference [1] Schulzrinne, H., "GIST: General Internet Signaling Transport", Internet Draft draft-ietf-nsis-ntlp-14, Work in progress , July 2007. [2] Manner, J., "NSLP for Quality-of-Service Signaling", Internet Draft draft-ietf-nsis-qos-nslp-15, Work in progress , July 2007. [3] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Internet Draft draft-ietf-nsis-nslp-natfw-15, Work in progress , July 2007. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Braden, B., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC2205 , September 1997. [6] Perkins, C., "IP Mobility Support for IPv4", RFC3344 , August 2002. [7] Johnson, D., "Mobility Support in IPv6", RFC3775 , June 2004. [8] Shen, C., "NSIS Operation Over IP Tunnels", Internet Draft draft-ietf-nsis-tunnel-03, Work in Progress , September 2007. 12.2. Informative References [9] Manner, J., "Mobility Related Terminology", RFC3753 , June 2004. [10] Wakikawa, R., "Multiple Care-of-Address Registration", Internet Draft draft-ietf-monami6-multiplecoa-03, Work in progress , July 2007. Sanda (Ed.), et al. Expires August 25, 2008 [Page 41] Internet-Draft NSIS Signaling in Mobility February 2008 Appendix A. The mobility occurs due to the change of the network attachment point, but the generic route changes is associated with load sharing, load balancing, or a link (or node) failure. These cause divergence (or convergence) between the old path along which state has already been installed and the new path along which data forwarding will actually happen. The route changes brings on the change of signaling topology and it results in difference according to the types of route changes (e.g., the route changes or mobility). The route changes generally forms two common paths, an old path, and a new path, where the old path and the new path begin to diverge from one common path and afterward to converge to another common path for each direction of signaling flows (e.g., downstream or upstream flows) as shown in Figure 10 Sanda (Ed.), et al. Expires August 25, 2008 [Page 42] Internet-Draft NSIS Signaling in Mobility February 2008 Old path +---+ +---+ ^ --->|NE | ... |NE | ------V common path ^ +---+ +---+ V common path +--+ +----+ +----+ +--+ |S |-----> |DCRN| |DCRN| -------> |R | | | | | | | | | +--+ +----+ New path +----+ +--+ V +---+ +---+ ^ V --->|NE | ... |NAR| ------^ +---+ +---+ =======(downstream signaling followed by data flows) ======> (a) The topology for downstream NSIS signaling flow after route changes Old path +---+ +---+ v <---|NE | ... |NE | ----- ^ common path v +---+ +---+ ^ common path +--+ +----+ +----+ +--+ |S |<----- |UCRN| |UCRN| <------- |R | | | | | | | | | +--+ +----+ New path +----+ +--+ ^ +---+ +---+ v ^ <---|NE | ... |NAR| ----- v +---+ +---+ <=====(upstream signaling followed by data flows) ====== (b) The topology for upstream NSIS signaling flow after route changes Figure 10: The topology for NSIS signaling in case of the route changes Sanda (Ed.), et al. Expires August 25, 2008 [Page 43] Internet-Draft NSIS Signaling in Mobility February 2008 Appendix B. As described in 7 of Section 3, An old AR may trigger for tearing down whole path before RESERVE from new location reaches to CRN. NSIS approach is that GIST is conservative and careful in indicating peer failure to the NSLP in mobile network. Another possible implementation approach to enhance the operation is that the MN informs AR (as adjacent QNE) or the CRN (including, HA and MAP) of its' handover with some sort of policy beforehand or afterward. Such a policy could, for example, indicate how it should be processed in case the MN suddenly moves away, or how long the AR may keep the QoS state after AR detects MN's handover (e.g., 30 sec., or until the MN moves back). In this case, the AR can be a proxy for the MN (the last node) and it may be able to send RESPONSE messages in response to REFRESH (or RESERVE) messages from an upstream node as well as avoid causing unnecessary teardown. Still other possible approach for latter case is the MN implicitly indicates which massages are sent from the latest location, e.g., the MN may embed a parameter to show the number of handover in the massages. By comparing these numbers, the CRN can detect the latest massage and avoid confusion. Sanda (Ed.), et al. Expires August 25, 2008 [Page 44] Internet-Draft NSIS Signaling in Mobility February 2008 Authors' Addresses Takako Sanda Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3, Hikarino-oka, Yokosuka City Kanagawa 239-0847 Japan Phone: +81 50 3687 6563 Email: sanda.takako@jp.panasonic.com Xiaoming Fu Computer Networks Group, University of Goettingen Lotzestr. 16-18 Goettingen 37083 Germany Email: fu@cs.uni-goettingen.de Seong-Ho Jeong Hankuk University of FS 89 Wangsan Mohyun Yongin-si, Gyeonggi-do 449-791 Korea Phone: +82 31 330 4642 Email: shjeong@hufs.ac.kr Jukka Manner Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) HELSINKI FIN-00014 Finland Phone: +358-9-191-44210 Email: jmanner@cs.helsinki.fi Sanda (Ed.), et al. Expires August 25, 2008 [Page 45] Internet-Draft NSIS Signaling in Mobility February 2008 Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich 81739 Germany Email: Hannes.Tschofenig@nsn.com Sanda (Ed.), et al. Expires August 25, 2008 [Page 46] Internet-Draft NSIS Signaling in Mobility February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Sanda (Ed.), et al. Expires August 25, 2008 [Page 47]