< draft-ietf-nsis-applicability-mobility-signaling-19.txt   draft-ietf-nsis-applicability-mobility-signaling-20.txt >
Next Steps in Signaling (nsis) T. Sanda (Ed.) Next Steps in Signaling (nsis) T. Sanda (Ed.)
Internet-Draft Panasonic Internet-Draft Panasonic
Intended status: Informational X. Fu Intended status: Informational X. Fu
Expires: January 7, 2011 University of Goettingen Expires: January 27, 2011 University of Goettingen
S. Jeong S. Jeong
HUFS HUFS
J. Manner J. Manner
TKK TKK
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
July 6, 2010 July 26, 2010
NSIS Protocols operation in Mobile Environments NSIS Protocols operation in Mobile Environments
draft-ietf-nsis-applicability-mobility-signaling-19.txt draft-ietf-nsis-applicability-mobility-signaling-20.txt
Abstract Abstract
Mobility of an IP-based node affects routing paths, and as a result, Mobility of an IP-based node affects routing paths, and as a result,
can have a significant effect on the protocol operation and state can have a significant effect on the protocol operation and state
management. This document discusses the effects mobility can cause management. This document discusses the effects mobility can cause
to the NSIS protocol suite, and shows how the NSIS protocols to the Next Steps in Signaling (NSIS) protocol suite, and shows how
operation can work in different scenarios, with mobility management the NSIS protocols operation can work in different scenarios, with
protocols. mobility management protocols.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2011. This Internet-Draft will expire on January 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Requirements Notation and Terminology . . . . . . . . . . . . 6 2. Requirements Notation and Terminology . . . . . . . . . . . . 6
3. Challenges with Mobility . . . . . . . . . . . . . . . . . . . 8 3. Challenges with Mobility . . . . . . . . . . . . . . . . . . . 8
4. Basic Operations for Mobility Support . . . . . . . . . . . . 11 4. Basic Operations for Mobility Support . . . . . . . . . . . . 11
4.1. General functionality . . . . . . . . . . . . . . . . . . 11 4.1. General functionality . . . . . . . . . . . . . . . . . . 11
4.2. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. NATFW NSLP . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. NATFW NSLP . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Localized signaling in mobile scenarios . . . . . . . . . 16 4.4. Localized signaling in mobile scenarios . . . . . . . . . 16
4.4.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 18 4.4.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 18
4.4.2. Localized State Update . . . . . . . . . . . . . . . . 18 4.4.2. Localized State Update . . . . . . . . . . . . . . . . 18
5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 20 5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 20
5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 20 5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 21
5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 23 5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 23
5.3. Interaction with Mobile IP tunneling . . . . . . . . . . . 24 5.3. Interaction with Mobile IP tunneling . . . . . . . . . . . 24
5.3.1. Sender-Initiated Reservation with Mobile IP tunnel . . 24 5.3.1. Sender-Initiated Reservation with Mobile IP tunnel . . 24
5.3.2. Receiver-Initiated Reservation with Mobile IP 5.3.2. Receiver-Initiated Reservation with Mobile IP
tunnel . . . . . . . . . . . . . . . . . . . . . . . . 27 tunnel . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.3. CRN discovery and State Update with Mobile IP 5.3.3. CRN discovery and State Update with Mobile IP
tunneling . . . . . . . . . . . . . . . . . . . . . . 29 tunneling . . . . . . . . . . . . . . . . . . . . . . 29
6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 31 6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. NSIS Operation in the multihomed mobile environment . . . 31 6.1. NSIS Operation in the multihomed mobile environment . . . 31
6.1.1. Selecting the best interface(s)/CoA(s) . . . . . . . . 31 6.1.1. Selecting the best interface(s)/CoA(s) . . . . . . . . 31
skipping to change at page 5, line 22 skipping to change at page 5, line 22
[draft-ietf-nsis-ntlp]). Local mobility usually does not cause the [draft-ietf-nsis-ntlp]). Local mobility usually does not cause the
change of the global IP addresses, but affects the routing paths change of the global IP addresses, but affects the routing paths
within the local access network within the local access network
The NSIS protocol suite consists of two layers: NSIS Transport Layer The NSIS protocol suite consists of two layers: NSIS Transport Layer
Protocol (NTLP) and the NSIS Signaling Layer Protocol (NSLP). The Protocol (NTLP) and the NSIS Signaling Layer Protocol (NSLP). The
General Internet Signaling Transport (GIST) [draft-ietf-nsis-ntlp] General Internet Signaling Transport (GIST) [draft-ietf-nsis-ntlp]
implements the NTLP, which is a signaling application independent implements the NTLP, which is a signaling application independent
protocol and transports service-related information between protocol and transports service-related information between
neighboring GIST nodes. Each specific service has its own NSLP neighboring GIST nodes. Each specific service has its own NSLP
protocol; currently there two standardized NSLP protocols, the QoS protocol; currently there are two specified NSLP protocols, the QoS
NSLP [draft-ietf-nsis-qos-nslp], and the NAT/Firewall NSLP NSLP [draft-ietf-nsis-qos-nslp], and the NAT/Firewall NSLP
[draft-ietf-nsis-nslp-natfw] [draft-ietf-nsis-nslp-natfw]
The goals of this document are to present the effects of mobility on The goals of this document are to present the effects of mobility on
the NTLP/NSLPs and to provide guides on how such NSIS protocols work the NTLP/NSLPs and to provide guides on how such NSIS protocols work
in basic mobility scenarios, including support for Mobile IPv4 and in basic mobility scenarios, including support for Mobile IPv4 and
Mobile IPv6 scenarios. We also show how these protocols fulfil the Mobile IPv6 scenarios. We also show how these protocols fulfil the
requirements regarding mobility set forth in [RFC3726]. In general, requirements regarding mobility set forth in [RFC3726]. In general,
the NSIS protocols work well in mobile environments. The Session ID the NSIS protocols work well in mobile environments. The Session ID
(SID) used in NSIS signaling enables the separation of the signaling (SID) used in NSIS signaling enables the separation of the signaling
skipping to change at page 6, line 24 skipping to change at page 6, line 24
The direction from a data sender towards the data receiver. The direction from a data sender towards the data receiver.
(2) Upstream (2) Upstream
The direction from a data receiver towards the data sender. The direction from a data receiver towards the data sender.
(3) Crossover Node (CRN) (3) Crossover Node (CRN)
A Crossover Node is a node that for a given function is a merging A Crossover Node is a node that for a given function is a merging
point of two or more paths belong to flows of the same session along point of two or more paths belonging to flows of the same session
which states are installed. along which states are installed.
In the mobility scenarios, there are two different types of merging In the mobility scenarios, there are two different types of merging
points in the network according to the direction of signaling flows points in the network according to the direction of signaling flows
followed by data flows, where we assume that the Mobile Node (MN) is followed by data flows, where we assume that the Mobile Node (MN) is
the data sender. the data sender.
Upstream CRN (UCRN): the node closest to the data sender from Upstream CRN (UCRN): the node closest to the data sender from
which the state information in the direction from data receiver to which the state information in the direction from data receiver to
data sender begins to diverge after a handover. data sender begins to diverge after a handover.
skipping to change at page 9, line 6 skipping to change at page 9, line 6
changes caused by node or link failure. This may result in a need to changes caused by node or link failure. This may result in a need to
speed up the update procedure of NSLP states. speed up the update procedure of NSLP states.
4. Identification of the crossover node 4. Identification of the crossover node
When a handover at the edge of a network has happened, in the typical 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 case, only some parts of the end-to-end path used by the data packets
changes. In this situation, the cross-over node (CRN) plays a changes. In this situation, the cross-over node (CRN) plays a
central role in managing the establishment of the new signaling central role in managing the establishment of the new signaling
application state, and removing any useless state, while localizing application state, and removing any useless state, while localizing
the signaling to only the affect part of the network. the signaling only to the affect part of the network.
5. Upstream State Update vs. Downstream State Update 5. Upstream State Update vs. Downstream State Update
Due to the asymmetric nature of Internet routing, the upstream and Due to the asymmetric nature of Internet routing, the upstream and
downstream paths are likely not to be exactly the same. Therefore, downstream paths are likely not to be exactly the same. Therefore,
state update needs to be handled independently for upstream and state update needs to be handled independently for upstream and
downstream paths. downstream paths.
6. Upstream signaling 6. Upstream signaling
skipping to change at page 13, line 9 skipping to change at page 13, line 9
among different operation modes of Mobile IP, and the main issue of among different operation modes of Mobile IP, and the main issue of
mobility support in NSIS is to trigger NSLP signaling appropriately mobility support in NSIS is to trigger NSLP signaling appropriately
when a handover event is detected, and the destination of the NSLP 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 shall follow the Mobile IP data path as being path-coupled
signaling. signaling.
In this process, the obsoleted state in the old path is not In this process, the obsoleted state in the old path is not
explicitly released because the state can be released by timer explicitly released because the state can be released by timer
expiration. To speed up the process, it may be possible to localize expiration. To speed up the process, it may be possible to localize
the signaling. When the RESERVE message reaches a node, depicted as the signaling. When the RESERVE message reaches a node, depicted as
CRN in this document (setp(2) in Figure 1), where a state is CRN in this document (step(2) in Figure 1), where a state is
determined for the first time to reflect the same session, the node determined for the first time to reflect the same session, the node
may issue a NOTIFY message towards the MN's old care-of-address (CoA) may issue a NOTIFY message towards the MN's old care-of-address (CoA)
(step(9) in Figure 1). The QNE adjacent to MN's old position stops (step(9) in Figure 1). The QNE adjacent to MN's old position stops
the NOTIFY message (step(10) in Figure 1), and sends RESERVE message the NOTIFY message (step(10) in Figure 1), and sends RESERVE message
(with Teardown bit set) towards the CN, to release the obsoleted (with Teardown bit set) towards the CN, to release the obsoleted
state (step(11) in Figure 1). This RESERVE with tear message is state (step(11) in Figure 1). This RESERVE with tear message is
stopped by the CRN (step(12) in Figure 1). The Reservation Sequence stopped by the CRN (step(12) in Figure 1). The Reservation Sequence
Number (RSN) used in the messages is used to distinguish the order of Number (RSN) used in the messages is used to distinguish the order of
the signaling. More details are described in Section 4.4 the signaling. More details are described in Section 4.4
skipping to change at page 15, line 8 skipping to change at page 15, line 8
Therefore, for the basic operation there is no fundamental difference Therefore, for the basic operation there is no fundamental difference
among different operation modes of Mobile IP, and the main issue of among different operation modes of Mobile IP, and the main issue of
mobility support in NSIS is to trigger NSLP signaling appropriately mobility support in NSIS is to trigger NSLP signaling appropriately
when a handover event is detected, and the destination of the NSLP 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 shall follow the Mobile IP data path as being path-coupled
signaling. signaling.
In this process, the obsoleted state in the old path is not In this process, the obsoleted state in the old path is not
explicitly released because the state can be released by timer explicitly released because the state can be released by timer
expiration. When the CREATE message reaches a node, depicted as CRN expiration. To speed up the process, when the CREATE message reaches
in this document (step(2) in Figure 2), where a state is determined a node, depicted as CRN in this document (step(2) in Figure 2), where
for the first time to reflect the same session, the node may issue a a state is determined for the first time to reflect the same session,
NOTIFY message towards the MN's old CoA (step(9) in Figure 2). the node may issue a NOTIFY message towards the MN's old CoA
(step(9)~(10) in Figure 2) and when the NI notices this, it sends a
CREATE message towards the CN to release the obsoleted state
(step(11)~(12)) in Figure 2).
MN NI MN NF1 NF2 NF3 CN MN NI MN NF1 NF2 NF3 CN
(CoA1) | (CoA2) | (CRN) | | (CoA1) | (CoA2) | (CRN) | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | |CREATE | | | | | | |CREATE | | | |
| | |------->| | | | | | |------->| | | |
| | | (1) |CREATE | | | | | | (1) |CREATE | | |
| | | |--------->| | | | | | |--------->| | |
| | | | (2) |CREATE | | | | | | (2) |CREATE | |
skipping to change at page 20, line 19 skipping to change at page 20, line 19
address changes. On the other hand, the MRI [draft-ietf-nsis-ntlp] address changes. On the other hand, the MRI [draft-ietf-nsis-ntlp]
contains flow addresses and will change if the CoA changes. This contains flow addresses and will change if the CoA changes. This
makes impact on some NSLPs such as QoS NSLP and NAT/FW NSLP. makes impact on some NSLPs such as QoS NSLP and NAT/FW NSLP.
QoS NSLP must be mobility-aware because it needs to care about the QoS NSLP must be mobility-aware because it needs to care about the
resources on the actual current path, and sending a new RESERVE or resources on the actual current path, and sending a new RESERVE or
QUERY for the new path. Applications on top of Mobile IP communicate QUERY for the new path. Applications on top of Mobile IP communicate
along logical flows that use home addresses, whereas QoS NSLP has to along logical flows that use home addresses, whereas QoS NSLP has to
be aware of the actual flow path, e.g., whether the flow is currently be aware of the actual flow path, e.g., whether the flow is currently
tunneled or route-optimized etc. QoS NSLP may have to obtain current tunneled or route-optimized etc. QoS NSLP may have to obtain current
link properties, esp. additional overhead due to mobility header link properties, especially additional overhead due to mobility
extensions that must be taken into account in QSPEC (e.g., the m header extensions that must be taken into account in QSPEC (e.g., the
parameter in the traffic model (TMOD)). Therefore, NSLPs must m parameter in the traffic model (TMOD)). Therefore, NSLPs must
interact with mobility management implementations in order to request interact with mobility management implementations in order to request
information about the current flow address (CoAs), source addresses, information about the current flow address (CoAs), source addresses,
tunneling, or, overhead. Furthermore, an implementation must select tunneling, or, overhead. Furthermore, an implementation must select
proper interface addresses in the NLI in order to ensure that a proper interface addresses in the natural language interface (NLI) in
corresponding Messaging Association is established along the same order to ensure that a corresponding Messaging Association is
path as the flow in the MRI. Moreover, the home agent needs to established along the same path as the flow in the MRI. Moreover,
perform additional actions (e.g., reservations) for the tunnel. If the home agent needs to perform additional actions (e.g.,
the home agent lacks support of a mobility-aware QoS NSLP a missing reservations) for the tunnel. If the home agent lacks support of a
tunnel reservation is usually the result. Practical problems may mobility-aware QoS NSLP a missing tunnel reservation is usually the
occur in situations where a home agent needs to send a GIST query result. Practical problems may occur in situations where a home
(with S-flag=1) towards the MN's Home Address and the query is not agent needs to send a GIST query (with S-flag=1) towards the MN's
tunneled due to route optimization between HA and MN: the query will Home Address and the query is not tunneled due to route optimization
be wrongly intercepted by QNEs within the tunnel. between HA and MN: the query will be wrongly intercepted by QNEs
within the tunnel.
NAT/FW box needs to be configured before MIP signaling, hence NAT/FW NAT/FW box needs to be configured before MIP signaling, hence NAT/FW
signaling will have to be performed, to allow RRT and Binding Update signaling will have to be performed, to allow Return Routability Test
(BU)/Binding Acknowledgement (BA) messages to traverse the NAT/FWs in (RRT) and Binding Update (BU)/Binding Acknowledgement (BA) messages
the path. After that the NAT/FW procedure more likes QoS NSLP to traverse the NAT/FWs in the path. After RRT and BU/BA are
(perform another NAT/FW signaling after BU). Optimized version can completed, another NAT/FW signaling needs to be performed for passing
include a combined NAT/FW message to cover both RTT and BU/BA the data. Optimized version can include a combined NAT/FW message to
messages pattern. However this may require NAT/FW NSLP to do a cover both RRT and BU/BA messages pattern. However this may require
slight update to support carrying multiple NAT/FW rules in one NAT/FW NSLP to do a slight update to support carrying multiple NAT/FW
signaling round trip. rules in one signaling round trip.
This section analyzes NSIS operation with tunneled route case This section analyzes NSIS operation with tunneled route case
especially for QoS NSLP. especially for QoS NSLP.
5.1. Interaction with Mobile IPv4 5.1. Interaction with Mobile IPv4
In Mobile IPv4 [RFC3344], the data flows are forwarded based on In Mobile IPv4 [RFC3344], the data flows are forwarded based on
triangular routing, and an MN retains a new CoA from the Foreign triangular routing, and an MN retains a new CoA from the Foreign
Agent (FA) (or an external method such as DHCP) in the visited access Agent (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 network. When the MN acts as a data sender, the data and signaling
 End of changes. 14 change blocks. 
38 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/