One document matched: draft-ietf-nsis-applicability-mobility-signaling-17.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="info"
docName="draft-ietf-nsis-applicability-mobility-signaling-17.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="NSIS Signaling in Mobility">NSIS
Protocols operation in Mobile Environments</title>
<author fullname="Takako Sanda" initials="T." surname="Sanda (Ed.)">
<organization abbrev="Panasonic">Panasonic Corporation</organization>
<address>
<postal>
<street>600 Saedo-cho, Tsuzuki-ku, Yokohama</street>
<city>Kanagawa</city>
<code>224-8539</code>
<country>Japan</country>
</postal>
<phone>+81 45 938 3056</phone>
<email>sanda.takako@jp.panasonic.com</email>
</address>
</author>
<author fullname="Xiaoming Fu" initials="X." surname="Fu">
<organization abbrev="University of Goettingen">Computer Networks Group,
University of Goettingen</organization>
<address>
<postal>
<street>Lotzestr. 16-18</street>
<city>Goettingen</city>
<code>37083</code>
<country>Germany</country>
</postal>
<!-- phone, unknown -->
<email>fu@cs.uni-goettingen.de</email>
</address>
</author>
<author fullname="Seong-Ho Jeong" initials="S." surname="Jeong">
<organization abbrev="HUFS">Hankuk University of FS</organization>
<address>
<postal>
<street>89 Wangsan Mohyun</street>
<city>Yongin-si, Gyeonggi-do</city>
<code>449-791</code>
<country>Korea</country>
</postal>
<phone>+82 31 330 4642</phone>
<email>shjeong@hufs.ac.kr</email>
</address>
</author>
<author fullname="Jukka Manner" initials="J." surname="Manner">
<organization abbrev="TKK">Helsinki University of Technology</organization>
<address>
<postal>
<street>P.O. Box 3000</street>
<city>Espoo</city>
<code>FIN-02015</code>
<country>Finland</country>
</postal>
<phone>+358 9 451 2481</phone>
<email>jukka.manner@tkk.fi</email>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization abbrev="Nokia Siemens Networks">Nokia Siemens
Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<street>Espoo</street>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 50 4871445</phone>
<email>Hannes.Tschofenig@nsn.com</email>
</address>
</author>
<date month="May" year="2010" />
<area>Transport</area>
<workgroup>Next Steps in Signaling (nsis)</workgroup>
<abstract>
<t>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 document discusses the effects mobility can cause to the
NSIS protocol suite, and how the protocols operate in different
scenarios, with mobility management protocols.</t>
</abstract>
</front>
<middle>
<!-- Start of L1 section -->
<section title="Introduction">
<t>Mobility of IP-based nodes incurs route changes, usually at the edge
of the network. Since IP addresses are usually part of flow identifiers,
the change of IP addresses implies the change of flow identifiers (i.e.,
the GIST message routing information or MRI <xref
target="draft-ietf-nsis-ntlp"></xref>). Local mobility usually does not cause the
change of the global IP addresses, but affects the routing paths within
the local access network</t>
<t>The NSIS protocol suite consists of two layers: NSIS Transport Layer
Protocol (NTLP) and the NSIS Signaling Layer Protocol (NSLP). The
General Internet Signaling Transport (GIST) <xref
target="draft-ietf-nsis-ntlp"></xref> implements the NTLP, which 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 <xref target="draft-ietf-nsis-qos-nslp"></xref>, and the NAT/Firewall
NSLP <xref target="draft-ietf-nsis-nslp-natfw"></xref></t>
<t>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 work in
basic mobility scenarios, including support for Mobile IPv4 and Mobile
IPv6 scenarios. We also show how these protocols fulfil the requirements
regarding mobility set forth in <xref target="RFC3726"></xref>.
In general, the NSIS protocols work well in mobile environments. The
efficiency of NSIS signaling is primarily an issue of software
engineering, e.g., which way an implementer chooses when implementing
the protocol functions, and how the coupling of the mobility management
protocols and the NSIS stack is implemented.</t>
<t>The Session ID (SID) used in NSIS signaling enables the separation of
the signaling state and the IP addresses of the communicating hosts.
This makes it possible to directly update a signaling state in the
network due to mobility without being forced to first remove the old
state and then re-establish a new one. This is the fundamental reason
why NSIS signaling works well in mobile environments.</t>
<t>A further important issue is that NSLPs must be aware of mobility,
i.e., routing and IP address changes. GIST has no semantics of an
end-to-end signaling session, only NSLPs have. Moreover, the Session ID
is effectively an NSLP layer concept.</t>
<t>This draft focuses on basic mobility scenarios. Key management
related to handovers, multihoming and interactions between NSIS and
other mobility management protocols than Mobile IP are 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.</t>
</section>
<!-- End of L1 section -->
<!-- End of Introduction -->
<!-- Start of L1 section -->
<section anchor="Terminology"
title="Requirements Notation and Terminology">
<!-- Editing memo: need to be re-written -->
<!--
<t> 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 <xref target="refs.RFC2119">RFC2119</xref>.</t>
-->
<t>The terminology in this draft is based on <xref
target="draft-ietf-nsis-ntlp"></xref> and <xref target="RFC3753"></xref>.
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 the route change caused by mobility is referred to
as 'mobility'.</t>
<t>(1) Downstream</t>
<t>The direction from a data sender towards the data receiver.</t>
<t>(2) Upstream</t>
<t>The direction from a data receiver towards the data sender.</t>
<t>(3) Crossover Node (CRN)</t>
<t>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
which states are installed.</t>
<t>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, where we assume that the
MN is the data sender. <list>
<t>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.</t>
<t>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.</t>
</list><!--End of List--></t>
<t>In general, the DCRN and the UCRN may be different due to the
asymmetric characteristics of routing although the data receiver is the
same.</t>
<t>(4) State Update</t>
<t>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 flows.
<list>
<t>Upstream State Update: State Update for the upstream signaling
flow.</t>
<t>Downstream State Update: State Update for the downstream
signaling flow.</t>
</list></t>
<!--
<t>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.</t>
-->
</section>
<!-- End of L1 section -->
<!-- End of Terminology -->
<!-- Start of L1 section -->
<section anchor="Problem.Statement" title="Challenges with Mobility">
<t>This
section identifies problems caused by mobility, which affect the
operations of NSIS protocol suite.</t>
<t>1. Change of route and possibly change of the MN's IP address</t>
<t>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. Traditional route changes usually do not cause address changes
of the flow endpoints. When an IP address changes due to mobility,
information within the path-coupled MRI is affected (the source or
destination address). Consequently, this concerns GIST as well as NSLPs,
e.g., the packet classifier in QoS NSLP or some rules carried in NAT/FW
NSLP. So already installed firewall rules, NAT bindings, and QoS
reservations may become invalid, because the installed states refer to a
non-existent flow. If the affected nodes are also on the new path, this
information must be updated accordingly.</t>
<!--
<t>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. </t>
-->
<t>2. Double state problem</t>
<t>After a handover, packets may end up getting delivered through a new
path. Since the state on the old path still remains as it was after
re-establishing the state along the new path, we have two separate
states for the same signaling session. Although the state on the old
path will be deleted automatically based on the soft state timeout, the
state timer value may be quite long (e.g., 90s as a default value). With
the QoS NSLP, this problem might result in the waste of resources and
lead to failure of admitting new reservations (due to lack of
resources). With the NAT/FW NSLP, it is still possible to re-use this
installed state although an MN roams to a new location; this means that
another host can send data through a firewall without any prior NAT/FW
NSLP signaling because the previous state did not yet expire.</t>
<!--
<t>NSIS solution: Removing old state in the network is a functionality 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?] </t>
-->
<t>3. End-to-end signaling and frequency of route changes</t>
<t>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 may result in a need to speed up
the update procedure of NSLP states.</t>
<!--
<t>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. </t>
-->
<t>4. Identification of the crossover node</t>
<t>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 cross-over node (CRN) plays a central
role in managing the establishment of the new signaling application
state, and removing any useless state, while localizing the signaling to
only the affect part of the network.</t>
<!--
<t>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. </t>
-->
<t>5. Upstream State Update vs. Downstream State Update</t>
<t>Due to the asymmetric nature of Internet routing, the upstream and
downstream paths are likely not to be exactly the same. Therefore,
state update needs to be handled independently for upstream and
downstream paths.</t>
<t>6. Upstream signaling</t>
<t>If the MN is receiver and moves to a new point of attachment,
it is difficult to signal upstream towards the CN.
New signaling states have to be established along the new
path, but for a path-coupled MRM this has to be initiated
in downstream direction. So NTLP signaling state in upstream
direction cannot be initiated by the MN, i.e., GIST cannot
easily send a Query in upstream direction (there is an
upstream Q-mode, but this is only applicable in a limited
scope). The use of additional other protocols such as
application level signaling (e.g, SIP) or mobility
management signaling (e.g., Mobile IP) may help to trigger
NSLP and NTLP signaling from the CN side in downstream
direction though.</t>
<t>7. Authorization Issues</t>
<t>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.</t>
<!--
<t>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. </t>
-->
<t>8. Dead peer and invalid NR problem</t>
<t>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'.</t>
<!--
<t>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. </t>
-->
<t>9. IP-in-IP Encapsulation</t>
<t>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 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. Furthermore, tunneling adds additional IP header as
overhead that must be taken into account by QoS NSLP
for example, when resources must be reserved accordingly.
So an NSLP must usually be aware whether tunneling or
route optimization is actually used for a flow <xref target="draft-ietf-nsis-tunnel"></xref>.</t>
<!--
<t>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. </t>
-->
</section>
<!-- End of L1 section -->
<!-- End of Challenges with Mobility -->
<!-- Start of L1 section -->
<section anchor="Basic.OP" title="Basic Operations for Mobility Support">
<t>This section presents the basic operations of the NSIS protocol suite
after mobility related route changes. Detailed discussion of the
operation of Mobile IP with respect to NSIS protocols are discussed in
the subsequent section.</t>
<!--
There may be two possible ways of operations:
<list>
<t>- 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. </t>
<t>- 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 <xref target="Int.with.mip4.mip6" />), 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.</t>
</list>
</t>
<t>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.</t>
<t>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.</t>
-->
<!-- Start of L2 section -->
<section title="General functionality">
<t>The NSIS protocol suite decouples state and flow identification. A
state is stored and referred by the Session ID (SID). Flows associated
with a given NSLP state are defined by the Message Routing Information
(MRI). GIST notices 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 by flow endpoints, and
when flow endpoint addresses change, the whole session state becomes
invalid.</t>
<t>A further benefit of the decoupling is that if the MRI, i.e., the
IP addresses associated with the data flow, remain the same after
movement, the NSIS signaling will repair only the affected path of the
end-to-end session. Thus, updating the session information in the
network will be localized, and no end-to-end signaling will be needed.
If the MRI changes, end-to-end signaling usually can not be avoided since new
information for proper data flow identification must be provided all
the way between the data sender and receiver, e.g.,
in order to update filters, QoS profiles, or other flow related
session data.</t>
<t>GIST provides NSLPs with an identifier of the next signaling peer,
the SII Handle. When this SII Handle changes, the NSLP knows a routing
change has happened. Yet, the NSLP can also figure out whether it is
also the crossover node for the session. Thus, CRN discovery is always
done at the NSLP layer because only NSLPs have a notion of end-to-end
signaling.</t>
<t>When a path changes, the session information on the old path needs
to be removed. After a routing change, the NSLP running on the
end-host or the CRN, depending on the direction of the session, can
use the SII Handle (provided by GIST) to remove states on the old
path; new session information is simultaneously set up on the new
path. Both current NSLPs use sequence numbers to identify the order of
messages, and this information can be used by the protocols to recover
from a routing change.</t>
<t>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.</t>
<t>If the signaling packets are encapsulated in a tunnel, 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.</t>
<t>Furthermore, in some cases the NSLP must be aware whether tunneling
is used, since additional tunneling overhead must be taken into
account, e.g., for resource reservations etc.</t>
</section>
<!-- End of L2 section -->
<!-- End of General functionality -->
<!-- Start of L2 section -->
<section anchor="Basic.OP.example" title="QoS NSLP">
<!--
<t>NSIS solution: Removing old state in the network is a functionality 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?] </t>
<t>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'.</t>
-->
<t>The following figure illustrates an example of QoS NSLP signaling
in a Mobile IPv6 route optimization case, for a 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 must get to know the new
care-of-address and update the path coupled MRI accordingly. Then the
MN issues a QoS NSLP RESERVE message towards the CN, that 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.</t>
<t>In a 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 <xref
target="Int.with.mip4.mip6"></xref></t>
<t>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.</t>
<t>In this process, the obsoleted state in the old path is not
explicitly released. To speed up the process, it may be possible to
localize the signaling. 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.
The RSN used in the messages is used to distinguish the order of the
signaling. More details are described in <xref
target="Localized.signaling.scenario"></xref></t>
<figure anchor="fig.Basic.OP.example" title="Basic operation example">
<preamble></preamble>
<artwork><![CDATA[
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) | | | |
| | | | | | |
| | | | | | |
]]></artwork>
</figure>
<t>Further cases to consider are:<list>
<t>* receiver-initiated reservation if MN is sender</t>
<t>* sender-initiated reservation if MN is receiver</t>
<t>* receiver-initiated reservation if MN is receiver</t>
</list><!--End of List--></t>
<t>In the first case, the MN can easily initiate a new QUERY
along the new path after movement, thereby installing signaling
state and eventually eliciting a new RESERVE from the CN in upstream
direction. Similarly, the second and third cases require
the CN to initiate a RESERVE or QUERY message respectively.
The difficulty in both cases is, however, to let the CN know
that the MN has moved. Because the MN is the receiver it cannot
simply use an NSLP message to do so, because upstream signaling
is not possible in this case (cf. Sec. 3, Upstream Signaling).</t>
</section>
<section title="NATFW NSLP">
<t>The following figure illustrates an example of NATFW NSLP signaling
in a Mobile IPv6 route optimization case, for a data flow from the MN
to the CN. The difference to the QoS NSLP is that for the NATFW NSLP
only the NSIS initiator (NI) can update the signalling session, in any
case. Once a handover event is detected in the MN, the MN must get to
know the new care-of- address and update the path coupled MRI
accordingly. Then the MN issues a NATFW NSLP CREATE message towards
the CN, that carries the unique session ID and other identification
information for the session. Upon receipt of the CREATE message, the
NATFW NSLP nodes (which will be discovered by the underlying NTLP)
establish the corresponding NATFW 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 NATFW NSLP
nodes along the path accept the required NAT/firewall configuration,
the CN in turn responds with a RESPONSE message, to confirm the
configuration.</t>
<t>In a bi-directional tunneling case, the only difference is that the
CREATE 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.</t>
<t>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.</t>
<t>In this process, the obsoleted state in the old path is not
explicitly released. When the CREATE 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.</t>
<t><figure anchor="fig.Basic.OP.exampleNATFW"
title="NATFW NSLP operation example">
<preamble></preamble>
<artwork><![CDATA[ MN NI MN NF1 NF2 NF3 CN
(CoA1) | (CoA2) | (CRN) | |
| | | | | | |
| | | | | | |
| | |CREATE | | | |
| | |------->| | | |
| | | (1) |CREATE | | |
| | | |--------->| | |
| | | | (2) |CREATE | |
| | | | |------->| |
| | | | | (3) |CREATE |
| | | | | |------->|
| | | | NOTIFY| | (4) |
| | | |<---------| | |
| | | NOTIFY| (9) | | |
| |<------------| | | |
| | | (10) | | | |
| |CREATE(CoA2) | | | |
| |------------>| | | |
| | | (11) |CREATE(CoA2) | |
| | | |--------->| | |
| | | | (12) | |RESPONSE|
| | | | | |<-------|
| | | | |RESPONSE| (5) |
| | | | RESPONSE|<-------| |
| | |RESPONSE|<---------| (6) | |
| | |<------ | (7) | | |
| | | (8) | | | |
| | | | | | |
| | | | | | |
]]></artwork>
</figure></t>
</section>
<!-- End of L2 section -->
<!--End of QoS NSLP-->
<!-- Start of L2 section -->
<section anchor="Localized.signaling.scenario"
title="Localized signaling in mobile scenarios">
<t>As shown in <xref target="fig.Top.NSIS.sig.caused.mob"></xref>,
mobility generally causes signaling path to either converge or diverge
depending on the direction of each signaling flow.</t>
<figure title="The topology for NSIS signaling caused by mobility" anchor="fig.Top.NSIS.sig.caused.mob">
<preamble></preamble>
<artwork>
<![CDATA[
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 ^
<=====(upstream signaling followed by data flows) =====
(a) The topology for upstream NSIS signaling flow due to
mobility (in case the MN is a data sender)
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 ^
====(downstream signaling followed by data flows) ======>
(b) The topology for downstream NSIS signaling flow due to
mobility (in case the MN is a data sender)
]]>
</artwork>
</figure>
<t>These topological changes due to mobility cause the NSIS state
established in the old path to be useless. Such state may be removed
as soon as possible. In addition, NSIS state needs to be established
along the new path and be updated along the common path. The
re-establishment of NSIS signaling may be localized when route 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.</t>
<!--
<t>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 <xref target="Problem.Statement" />.</t>
-->
<!-- Start of L3 section -->
<section anchor="CRN.discovery" title="CRN Discovery">
<t>The CRN is discovered at the 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 the
handover, for sender-oriented and receiver-oriented reservations,
respectively. And realizes it is implicitly the CRN.</t>
<!-- <t>The NTLP layer can easily detect route changes by tracking the SII-Handle of sessions. Thus, in theory, it would be possible to also discover the CRN at the NTLP layer since the NTLP is responsible for detecting the path change of data (or signaling) flow. However, in practice a routing change primarily affects an NSLP and its internal state and next peers, and this change is out of scope of NTLP which is mainly concerned with hop-by-hop transport of signaling messages. Thus, all the logic for CRN discovery and how it affects the application layer is ultimately the task of NSLP.</t>
<t>There can also be two different approaches for the CRN discovery messaging depending on whether or not the discovery is coupled with a signaling message: coupled approach and uncoupled approach. In the coupled approach, the signaling to install the NSIS state along the new path or update the state along the common path is performed simultaneously with the CRN discovery. In the uncoupled approach, the signaling for the State Update is performed after the CRN discovery is completed. These two approaches may differ in terms of security. Generally, the coupled approach in the NSIS protocol suit is preferred to the uncoupled approach to reduce the delay for state update. </t> -->
</section>
<!-- End of L3 section-->
<!--End of CRN Discovery-->
<!-- Start of L3 section -->
<section anchor="State.setup.and.update"
title="Localized State Update">
<!--
<t>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.</t>
-->
<t>In the downstream State Update, the MN initiates the 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
<xref target="CRN.discovery"></xref>. 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 the edge QNE
(i.e., QNE1 in <xref target="fig.Basic.OP.example"></xref>). After
the QNE is aware that the MN as QNI has disappeard (how this is can
be noticed is out of scope of NSIS, yet, e.g., GIST will eventually
no this through undelivered messages), the QNE sends a tearing
RESERVE towards downstream. When the tearing RESERVE reaches the
DCRN, it stops forwarding and drops it. Note that, however, it is
not necessary for GIST state to be explicitly removed because of the
inexpensiveness of the state maintenance at the GIST layer <xref
target="draft-ietf-nsis-ntlp"></xref>. Note that, the sender-initiated approach
leads to faster setup than the receiver-initiated approach as in
RSVP <xref target="RFC2205"></xref>.</t>
<t>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 upon receiving trigger (e.g., MIP binding update). UCRN
is discovered implicitly by the CN-initiated signaling along the
common path as described in <xref target="CRN.discovery"></xref>.
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 RESERVE with full QSPEC 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
has disappeard, the QNE drops the tearing peer. Another method is,
if GIST hop is already established on the new path (e.g. by QUERY
from the CN, or the HA/GFA/ 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 RESERVE with a new RSN and an RII towards the
MN. By receiving the 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 disappeared, the QNE drops
the tearing peer.</t>
<t>The State Update on the common path to reflect the changed MRI
brings issues on the end-to-end signaling addressed in <xref
target="Problem.Statement"></xref>. 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.</t>
<t>One of the goals of the State Update is to avoid the double
reservation on the common path as described in <xref
target="Problem.Statement"></xref>. 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/MRI. In this case, even though the flows on the common
path have different MRIs, it refers to the same NSLP state.</t>
</section>
<!-- End of L3 section-->
<!--End of State setup and update-->
</section>
<!-- End of L2 section -->
<!--End of Localized signaling in mobile scenarios-->
<!-- Start of L2 section -->
<!-- <section title="NAT/FW NSLP" anchor="natfw-section">
<t>
THIS SECTION IS FOR MARTIN, HANNES ET AL.
</t>
</section> -->
<!-- End of L2 section -->
<!-- End Of NATFW NSLP -->
</section>
<!-- End of L1 section -->
<!-- End of "Basic Operations for Mobility Support" section -->
<!-- Start of L1 section -->
<section anchor="Int.with.mip4.mip6"
title="Interaction with Mobile IPv4/v6">
<t>Mobility management solutions like Mobile IP try to hide mobility
effects from applications by providing stable addresses and avoiding
address changes. On the other hand, the PC-MRI <xref target="draft-ietf-nsis-ntlp"></xref> contains flow addresses
and will change if the CoA changes. This makes impact on some NSLPs such
as QoS NSLP and NAT/FW NSLP.</t>
<t>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 QUERY
for the new path. Applications on top of Mobile IP communicate 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 tunneled or
route-optimized etc. QoS NSLP may have to obtain current link
properties, esp. additional overhead due to mobility header extensions
that must be taken into account in QSPEC (e.g., the m parameter in the
TMOD). Therefore, NSLPs must interact with mobility management
implementations in order to request information about the current flow
address (CoAs), source addresses, tunneling, or, overhead. Furthermore,
an implementation must select proper interface addresses in the NLI in
order to ensure that a corresponding Messaging Association is
established along the same path as the flow in the MRI. Moreover, the
home agent needs to perform additional actions (e.g., reservations) for
the tunnel. If the home agent lacks support of a mobility-aware QoS NSLP
a missing tunnel reservation is usually the result. Practical problems
may occur in situations where a home agent needs to send a GIST query
(with S-flag=1) towards the MN's Home Address and the query is not
tunneled due to route optimization between HA and MN: the query will be
wrongly intercepted by QNEs within the tunnel.</t>
<t>NAT/FW box needs to be configured before MIP signaling, hence NAT/FW
signaling will have to be performed, to allow RRT and BU/BA messages to
traverse the NAT/FWs in the path. After that the NAT/FW procedure more
likes QoS NSLP (perform another NAT/FW signaling after BU). Optimized
version can include a combined NAT/FW message to cover both RTT and
BU/BA messages pattern. However this may require NAT/FW NSLP to do a
slight update to support carrying multiple NAT/FW rules in one signaling
round trip.</t>
<t>This section analyzes NSIS operation with tunneled route case
especially for QoS NSLP.</t>
<!-- Start of L2 section -->
<section anchor="Int.with.MIP4" title="Interaction with Mobile IPv4">
<t>In Mobile IPv4 <xref target="RFC3344"></xref>, 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 tunneling. 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.</t>
<t>The <xref target="fig.mip4"></xref> (a) to (e) show the NSIS
signaling flows depending on the direction of the data flows and the
routing methods.</t>
<figure anchor="fig.mip4"
title="NSIS signaling flows under different Mobile IPv4 scenarios">
<preamble></preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t>When an MN (as a signaling sender) arrives at a new FA and the
corresponding binding process is completed (<xref
target="fig.mip4"></xref> (a), (b) and (c)), the MN performs the CRN
discovery (DCRN) and the State Update toward the CN (as described in
<xref target="Basic.OP"></xref>) to establish the NSIS state along the
new path between the MN and the CN. In case reverse tunnel is not used
(<xref target="fig.mip4"></xref> (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 (<xref target="fig.mip4"></xref> (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 (<xref target="fig.mip4"></xref> (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.</t>
<t>When an MN (as a signaling receiver) arrives at a new FA and the
corresponding binding process is completed (<xref
target="fig.mip4"></xref> (d) and (e)), the MN sends NOFITY message to
the signaling sender, i.e., the CN. In case FA CoA is used (<xref
target="fig.mip4"></xref> (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 MRI 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 (<xref target="fig.mip4"></xref> (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.</t>
<t>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.</t>
</section>
<!-- End of L2 section -->
<!-- End of Interaction with Mobile IPv4 -->
<!-- Start of L2 section -->
<section anchor="Int.with.MIP6" title="Interaction with Mobile IPv6">
<t>Unlike Mobile IPv4, with Mobile IPv6 <xref
target="RFC3775"></xref>, 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.</t>
<t>If the route optimization is not used, 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 <xref
target="Basic.OP"></xref> are applicable to this case.</t>
</section>
<!-- End of L2 section -->
<!-- End of Interaction with Mobile IPv6 -->
<!-- Start of L2 section -->
<section anchor="Int.with.MIPtunnel"
title="Interaction with Mobile IP tunneling">
<t>In this section, we assume that MN acts as an NI and CN acts as an
NR in interworking between Mobile IP and NSIS signaling.</t>
<t>Scenarios for interaction with Mobile IP tunneling vary depending
on: <list>
<t>- 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).</t>
<t>- Whether the mode of QoS-NSLP signaling is sender-initiated or
receiver initiated.</t>
<t>- 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 <xref
target="draft-ietf-nsis-tunnel"></xref>.</t>
</list></t>
<t>The following subsection describes sender-initiated and
receiver-initiated reservation with Mobile IP tunneling and CRN
discovery and State Update with Mobile IP tunneling.</t>
<!-- Start of L3 section -->
<section anchor="Int.with.MIPtunnel.SI"
title="Sender-Initiated Reservation with Mobile IP tunnel">
<t>The following scenario assumes that a FA is a Tentry. However the
procedure is the same for the case an MN is a Tentry if it is
considered that the MN and the FA are the same node. <list>
<t>- 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 tunneling path is transparent as a
logical link to NSIS signaling <xref
target="draft-ietf-nsis-tunnel"></xref>.</t>
<t>- In the NSIS-aware tunneling scenarios, as shown in <xref
target="fig.miptunnel.SI.SE"></xref> and <xref
target="fig.miptunnel.SI.PA"></xref>, 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) MRI
different from the (end-to-end) MRI, 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.</t>
<t>- 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.</t>
<t>- Provided that the tunnel signaling mode is sequential as
shown in <xref target="fig.miptunnel.SI.SE"></xref>, 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.</t>
<t>- Provided that the tunnel signaling mode is parallel as
shown in <xref target="fig.miptunnel.SI.PA"></xref>, upon
receiving the RESERVE message from the MN, the FA forwards it to
the HA immediately. 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.</t>
</list></t>
<figure anchor="fig.miptunnel.SI.SE"
title="Sender-Initiated QoS-NSLP over Tunnel - Sequential Mode">
<preamble></preamble>
<artwork><![CDATA[
MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver)
| | | | |
| RESERVE | | | |
+--------->| | | |
| |RESERVE-t | | |
| +=========>| | |
| | |RESERVE-t | |
| | +=========>| |
| | |RESPONSE-t| |
| | |<=========+ |
| |RESPONSE-t| | |
| |<=========+ | |
| | RESERVE | |
| +-------------------->| |
| | | | RESERVE |
| | | +--------->|
| | | | RESPONSE |
| | | |<---------+
| | RESPONSE | |
| |<--------------------+ |
| RESPONSE | | | |
|<---------+ | | |
| | | | |
]]></artwork>
</figure>
<figure anchor="fig.miptunnel.SI.PA"
title="Sender-Initiated QoS NSLP over Tunnel - Parallel Mode">
<preamble></preamble>
<artwork><![CDATA[
MN (Sender) FA (Tentry) Tnode HA (Texit) CN (Receiver)
| | | | |
| RESERVE | | | |
+--------->| | | |
| |RESERVE-t | | |
| +=========>| | |
| | |RESERVE-t | |
| | +=========>| |
| | RESERVE | |
| +-------------------->| |
| | | | RESERVE |
| | | +--------->|
| | | | RESPONSE |
| | | |<---------+
| | |RESPONSE-t| |
| | |<=========+ |
| |RESPONSE-t| | |
| |<=========+ | |
| | RESPONSE | |
| |<--------------------+ |
| RESPONSE | | | |
|<---------+ | | |
| | | | |
]]></artwork>
</figure>
</section>
<!-- End of L3 section -->
<!-- End of Sender-Initiated Reservation with Mobile IP tunnel-->
<!-- Start of L3 section -->
<section anchor="Int.with.MIPtunnel.RI"
title="Receiver-Initiated Reservation with Mobile IP tunnel">
<t><xref target="fig.miptunnel.RI.SE"></xref> and <xref
target="fig.miptunnel.RI.PA"></xref> 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.</t>
<figure anchor="fig.miptunnel.RI.SE"
title="Receiver-Initiated QoS NSLP over Tunnel - Sequential Mode">
<preamble></preamble>
<artwork><![CDATA[
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 |
| | | +--------->|
| | | | |
]]></artwork>
</figure>
<figure anchor="fig.miptunnel.RI.PA"
title="Receiver-Initiated QoS NSLP over Tunnel - Parallel Mode">
<preamble></preamble>
<artwork><![CDATA[
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 |
| | | +--------->|
| | | | |
]]></artwork>
</figure>
</section>
<!-- End of L3 section -->
<!-- End of Receiver-Initiated Reservation with Mobile IP tunnel-->
<!-- Start of L3 section -->
<section title="CRN discovery and State Update with Mobile IP tunneling">
<t>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.</t>
<t>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 <xref target="draft-ietf-nsis-qos-nslp"></xref></t>
<t>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 <xref target="Basic.OP"></xref> are applicable to this
case.</t>
</section>
<!-- End of L3 section -->
<!-- End of CRN discovery and State Update with Mobile IP tunneling-->
</section>
<!-- End of L2 section -->
<!-- End of Interaction with Mobile IP tunnneling-->
</section>
<!-- End of L1 Section -->
<!-- End of Interaction with Mobile IPv4/v6-->
<!-- Start of L1 section -->
<section anchor="Further.Studies" title="Further Studies">
<t>All sections above dealt with basic issues on NSIS mobility support.
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, which may need to be resolved in the future. Topics in this
section are out-of-scope of this document, and detailed operations are
not described.</t>
<!-- Start of L2 section -->
<section title="NSIS Operation in the multihomed mobile environment">
<t>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.</t>
<!-- Start of L3 section -->
<section title="Selecting the best interface(s)/CoA(s)">
<t>In MIPv6 route optimization case, if multiple CoAs registration
is provided <xref target="RFC5648"></xref>, the contents of
QUERYs sent by candidate CoAs can be used to select the best
interface(s)/CoA(s).</t>
<t>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.</t>
<t>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.</t>
<figure title="Receiver-initiated reservation in the multihomed environment">
<preamble></preamble>
<artwork><![CDATA[
|--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)-----| (MRI |
| | | | (Actual reservation) | Update) |
|<----RESERVE(7)-----| | | | | |
| | | | | | | | |
| |<-----------teardown(8)-------------| | |
| | | | | | | | |
| | | | Multimedia Traffic | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
]]></artwork>
</figure>
</section>
<!-- End of L3 section -->
<!-- End of Selecting the best interface(s)/CoA(s)-->
<!-- Start of L3 section -->
<section title="Differentiation of two types of CRNs">
<t>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.</t>
<t>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 <xref
target="fig.pathtype"></xref>. 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 <xref target="fig.pathtype"></xref>. 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, 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.</t>
<figure anchor="fig.pathtype"
title="The topology for NSIS signaling in multihomed mobile environments">
<preamble></preamble>
<artwork><![CDATA[
+--+ 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
]]></artwork>
</figure>
</section>
<!-- End of L3 section -->
<!-- End of Differentiation of two types of CRNs-->
</section>
<!-- End of L2 section -->
<!-- End of NSIS Operation in the multihomed mobile environment-->
<!-- Start of L2 section -->
<section title="Interworking with other mobility protocols">
<t>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.</t>
<t>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 <xref target="RFC4066"></xref> and CXTP <xref target="RFC4067"></xref>) 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.</t>
</section>
<!-- End of L2 section -->
<!-- End of Interworking with other mobility protocols-->
<!-- Start of L2 section -->
<section title="Intermediate node becomes a dead peer">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<!-- End of L2 section -->
<!-- End of Intermediate node becomes dead peer-->
</section>
<!-- End of L1 section -->
<!-- End of Further Study -->
<!-- Start of Security Consideration Section -->
<!-- Start of L1 section -->
<section anchor="Security.Considerations" title="Security Considerations">
<t>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.</t>
</section>
<!-- End of L1 section -->
<!-- End of Security Considerations -->
<!-- Start of IANA Considerations -->
<!-- Start of L1 section -->
<section anchor="IANA.Considerations" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<!-- End of L1 section -->
<!-- End of IANA Considerations -->
<!-- Start of Open Issues -->
<!-- Start of L1 section -->
<!-- Closing Open Issues
<section title="Open Issues">
<t>1. MIP Interaction Part (<xref target="Int.with.mip4.mip6"></xref>)
<list>
<t>- This section should illustrate how Tunnel I-D is applicable to
MIP cases.</t>
<t>Discussion: How does this section should be cleaned up?</t>
</list></t>
</section>
-->
<!-- End of L1 section -->
<!-- Start of Change History -->
<!-- Start of L1 section -->
<section title="Change History">
<!-- Start of L2 section -->
<t>[Note to the RFC editor: Please remove this section before publication]</t>
<section title="Changes from -00 version">
<t>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.</t>
<t>Specifically, the following changes have been made: <list
style="numbers">
<t>Removed the terminologies, 'uplink' and 'downlink' in Section
2.</t>
<t>Removed the terminology, 'local repair' in Sections 2 and
4.</t>
<t>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.</t>
<t>Removed the general considerations section in Section 3.</t>
<t>Modified the problem statement section and moved it into the
general problem section in Section 3.1.</t>
<t>Added more problems including 'Identification of the crossover
node', 'Key exchanges', and 'AA-related Issues' to Section 3.1</t>
<t>Added the 'Multihoming-related issues' to Section 3.2.4</t>
<t>Removed the issues on 'how to immediately delete the state on
the old path' in Section 3.2.</t>
<t>Moved the generic route changes-related text in Section 4.1
into Appendix.</t>
<t>Removed the figure describing "NSIS signaling topology for
downstream signaling flow after the route changes in the middle of
the network" in Figure 2.</t>
<t>Added 'NSLP_IDs' to each node in Figure 1.</t>
<t>Removed the 'use cases of identifiers' section, and instead,
added the 'support for ping-pong type handover' section to
Section5.</t>
<t>Added this change history.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -01 version">
<t>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: <list
style="numbers">
<t>Defined the terminologies, 'route change' and 'mobility' in
Section 2.</t>
<t>Clarified the terminology, 'Crossover node (CRN)' in Section
2.</t>
<t>Removed the terminology, 'mobility CRN' in Section 2.</t>
<t>The issue, 'Priority of signaling messages' in Section 3.2.2
was closed, and thus removed it.</t>
<t>Clarified the issue, 'CRN discovery and State Update on the
IP-tunneling path in Section 3.2.4.</t>
<t>Added the pros and cons of two mechanisms on CRN discovery
dependent on NSIS layers to Section 4.2.1.</t>
<t>Clarified the identifier, NSLP_Br_ID for CRN discovery in
Section 4.2.2.</t>
<t>Added the scenario on interaction between NSIS and Mobile IP to
Section 5.1.</t>
<t>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.</t>
<t>1Clarified interaction issues between NSIS protocols and
IP-tunneling in Mobile IPv6 and added those to Section
5.1.1.2.</t>
<t>Clarified the multihoming-related issues in Section 5.2.</t>
<t>Added the issues on usage of 'hint' information to trigger NSIS
signaling in mobility to Section 5.5.</t>
<t>Identified the dead peer-related issues in Mobile IP-based
scenario in Section 5.5.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -02 version">
<t>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.</t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -03 version">
<t>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: <list
style="numbers">
<t>The issue, 'Peering agreement issue' in Section 3.2.2 was
closed, and thus removed it.</t>
<t>Clarified the issue, 'Interfaces between Mobile IP and NSIS
protocols' in Section 3.2.1.</t>
<t>Clarified the issue, 'Authorization-related issues with
teardown' in Section 3.2.2.</t>
<t>Clarified the issue, 'Dead peer discovery' in Section
3.2.2.</t>
<t>Clarified the issue, 'Invalid NR problem' in Section 3.2.2.</t>
<t>Clarified the issue, 'CRN discovery and State Update on the
IP-tunneling path' in Section 3.2.4.</t>
<t>Clarified the issue, 'Multihoming-related issues' in Section
3.2.4.</t>
<t>Changed Figure 1 (a) into (b) in Section 4.1.</t>
<t>Changed Figure 1 (b) into (a) in Section 4.1.</t>
<t>Clarified the identifier, NSLP_Br_ID for CRN discovery in
Section 4.2.2.</t>
<t>Clarified the identifier, Mobility identifier for CRN discovery
in Section 4.2.2.</t>
<t>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.</t>
<t>Clarified the issues on 'interaction with Mobile IP tunneling'
and added those to Section 5.1.4.</t>
<t>Clarified the issues on 'load balancing in multihomed mobile
environments' and added those to Section 5.2.5.</t>
<t>Changed Problems of the heading name in Section 3.2 into
Challenges.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -04 version">
<t>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: <list
style="numbers">
<t>'Explicit routes' in Section 3.1 (3) was removed.</t>
<t>Clarified the problem, 'Double reservation problem' in Section
3.1 (7).</t>
<t>Clarified the issue, 'CRN discovery-related issues' in Section
3.2.4 (1).</t>
<t>Clarified the issue, 'Issues on API between NTLP and NSLP' in
Section 3.2.4 (3).</t>
<t>Clarified the issue, 'approaches for CRN discovery' in Section
4.2.1.</t>
<t>Changed NSLP_Br_ID (of identifiers for CRN discovery) into
State_Br_ID in Section 4.2.2 for clarification.</t>
<t>Clarified the issue, 'double reservation problem on the common
path' in Section 4.3.1.</t>
<t>Clarified the issue, 'Interfaces between Mobile IP and NSIS' in
Section 5.1.1.</t>
<t>Removed the sencond paragraph on the issue, 'Explicit routes'
in Section 4.1.</t>
<t>Clarified the issue, 'refresh timer value in mobility
scenarios' in Section 5.3.</t>
<t>Removed the third paragraph on the issue, 'usage of Reservation
Sequence Number (RSN) to support ping-pong type hanover' in
Section 5.4.</t>
<t>Clarified the issues on 'peer failure' in Section 5.5.</t>
<t>Removed Figure 3 'Sender- vs. Receiver-initiated reservation'
in Section 4.3.1.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -05 version">
<t>In Version -06, contents of this draft were re-selected and
re-structured: <list style="numbers">
<t>Section 4 and 5 of -05 were divided into two parts: <list>
<t>'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 (<xref target="Basic.OP"></xref> and <xref
target="Int.with.mip4.mip6"></xref> in -06)</t>
<t>'Further Study' part, which introduces summary of potential
issues and possible approaches for other topics. These topics
are out-of-scope for discussing details (<xref
target="Further.Studies"></xref> in -06)</t>
</list><!--End of Nested List--></t>
<t>Specific parameters and terms were removed from 'Main' part</t>
<t>Showing similar detailed operations were avoided in
'Interaction with MIP tunneling section (<xref
target="Int.with.MIPtunnel"></xref>)'</t>
<t>In Further Study section <xref
target="Further.Studies"></xref>: <list>
<t>Detailed operations were removed</t>
<t>Ping-pong issue was removed</t>
</list><!--End of Nested List--></t>
<t>Problem Statement (<xref target="Problem.Statement"></xref>)
was cleaned up</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -06 version">
<t>Changes in Version -07 are: <list style="numbers">
<t>'Invalid NR problem' are moved from Further Study section</t>
<t>Figure 7 (Receiver-Initiated QoS NSLP over Tunnel -Parallel
Mode) are changed</t>
<t>Terminologies 'NSLP CRN', 'NTLP CRN' 'NSIS CRN'
'Divergent-convergent UCRN' and 'Divergent-convergent DCRN' are
removed from Terminology section.</t>
<t>'Open Issues' section is added</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -07 version">
<t>Changes in Version -08 are: <list style="numbers">
<t>Figure 1 was updated (NOTIFY message from CRN is added)</t>
<t>Section 4.2.1 (CRN discovery) was updated to be synchronized
with QoS-NSLP draft</t>
<t>Title of Section 4.2.2 was changed from "State setup and
update" to "Localized State Update"</t>
<t>Section 4.2.2 (Localized State Update) was updated to be
synchronized with QoS-NSLP draft</t>
<t>Section 4.2.3 (State teardown) was deleted because the issues
was already solved</t>
<t>Title of Section 4.2.3 was changed to "State teardown
consideration"</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -08 version">
<t>Changes in Version -09 are: <list style="numbers">
<t>Security Consideration Section (Section 7) was cleaned up.</t>
<t>Security Consideration issue was removed from Open Issue
section (Section 8).</t>
<t>NAT traversal issues were removed from Open Issue section
(Section 8).</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -09 version">
<t>Changes in Version -10 are: <list style="numbers">
<t>Introduction was updated accordingly.</t>
<t>Definition of RFC2119 terms were removed from Section 2</t>
<t>Definition of Upstream/Downstream State Update were cleaned
up</t>
<t>Title of Section 3 was changed from "Problem Statement" to
"Challenges with Mobility"</t>
<t>NSIS solutions are removed from Section 3</t>
<t>Section 4 was cleaned up</t>
<t>More detailed description was added to Section 5</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -10 version">
<t>Change in Version -11 is: <list style="numbers">
<t>Introduction part of Section 5 was updated.</t>
</list></t>
</section>
<section title="Changes from -11 version">
<t>Change in Version -12 are: <list style="numbers">
<t>Section 4.3 (NATFW section) was added.</t>
<t>Open Issue section was closed.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -12 version">
<t>Changes in Version -13 are: <list style="numbers">
<t>"Upstream signaling" was added to Section 3</t>
<t>Three more cases were discussed in Section 4.2</t>
<t>Definition of Upstream/Downstream State Update were cleaned
up</t>
<t>Figure 3 was removed because it was't really necessary for the discussion.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -13 version">
<t>Change in Version -14 is: <list style="numbers">
<t>Figure 3 was re-added with appropriate changes.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -14 version">
<t>Change in Version -15 is: <list style="numbers">
<t>Title was changed because this draft is not talking about AS.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -15 version">
<t>Changes in Version -16 are: <list style="numbers">
<t>RFC2205, RFC3726, RFC3753 and draft-ietf-nsis-tunnel were changed from Normative references to Informative references.</t>
<t>IANA Consideration was added.</t>
<t>RFC4066 and RFC4067 was added to Informative References.</t>
</list></t>
</section>
<!-- End of L2 section -->
<!-- Start of L2 section -->
<section title="Changes from -16 version">
<t>Changes in Version -17 is: <list style="numbers">
<t>Some editorial changes were made.</t>
</list></t>
</section>
<!-- End of L2 section -->
</section>
<!-- End of L1 section -->
<!-- End of Change History -->
<!-- Start of Contributors Section -->
<section title="Contributors">
<t>Sung-Hyuck Lee was the first editor of the draft. Since version 06 of
the draft, Takako Sanda has taken the editorship.</t>
<t>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, Shivanajay Marwaha and Martin Stiemerling.
Separating authors into two groups was done without treating any one of
them better (or worse) than others.</t>
</section>
<!-- End of Contributors Section -->
<!-- Start of Acknowledgements Section -->
<section title="Acknowledgements">
<t>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, Pratic Bose, Martin Stiemerling
and Luis Cordeiro for their useful comments and suggestions.</t>
</section>
<!-- End of Acknowledgements Section -->
</middle>
<!-- End of Middel portion -->
<back>
<references title="Normative Reference">
<reference anchor="draft-ietf-nsis-ntlp">
<front>
<title>GIST: General Internet Signaling Transport</title>
<author fullname="Schulzrinne H. and Hancock R." initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2009" />
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-nsis-ntlp-20" />
<seriesInfo name="Work in progress" value="" />
</reference>
<reference anchor="draft-ietf-nsis-qos-nslp">
<front>
<title>NSLP for Quality-of-Service Signaling</title>
<author fullname="Manner J., et al." initials="J." surname="Manner">
<organization></organization>
</author>
<date month="January" year="2010" />
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-nsis-qos-nslp-18" />
<seriesInfo name="Work in progress" value="" />
</reference>
<reference anchor="draft-ietf-nsis-nslp-natfw">
<front>
<title>NAT/Firewall NSIS Signaling Layer Protocol (NSLP)</title>
<author fullname="Stiemerling M., et al." initials="M."
surname="Stiemerling">
<organization></organization>
</author>
<date month="April" year="2010" />
</front>
<seriesInfo name="Internet Draft"
value="draft-ietf-nsis-nslp-natfw-25" />
<seriesInfo name="Work in progress" value="" />
</reference>
<reference anchor="RFC3344">
<front>
<title>IP Mobility Support for IPv4</title>
<author fullname="Perkins C., Ed." initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="August" year="2002" />
</front>
<seriesInfo name="RFC3344" value="" />
</reference>
<reference anchor="RFC3775">
<front>
<title>Mobility Support in IPv6</title>
<author fullname="Johnson D., Perkins C. and Arkko J." initials="D."
surname="Johnson">
<organization></organization>
</author>
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC3775" value="" />
</reference>
</references>
<!-- End of Normative Reference -->
<!-- Start of Informative Reference -->
<references title="Informative References">
<reference anchor="draft-ietf-nsis-tunnel">
<front>
<title>NSIS Operation Over IP Tunnels</title>
<author fullname="Shen C., et al.," initials="C." surname="Shen">
<organization></organization>
</author>
<date month="April" year="2010" />
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-nsis-tunnel-10" />
<seriesInfo name="Work in Progress" value="" />
</reference>
<reference anchor="RFC2205">
<front>
<title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification</title>
<author fullname="Braden, B., Zhang, L., Berson, S., Herzog, S., and Jamin S."
initials="B." surname="Braden">
<organization></organization>
</author>
<date month="September" year="1997" />
</front>
<seriesInfo name="RFC2205" value="" />
</reference>
<reference anchor="RFC3726">
<front>
<title>Requirements for Signaling Protocols</title>
<author fullname="Brunner, (Ed)" initials="M."
surname="Brunner, (Ed)">
<organization></organization>
</author>
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC3726" value="" />
</reference>
<reference anchor="RFC3753">
<front>
<title>Mobility Related Terminology</title>
<author fullname="Manner, J. and Kojo, M." initials="J."
surname="Manner">
<organization></organization>
</author>
<date month="June" year="2004" />
</front>
<seriesInfo name="RFC3753" value="" />
</reference>
<reference anchor="RFC5648">
<front>
<title>Multiple Care-of-Address Registration</title>
<author fullname="Wakikawa, R." initials="R." surname="Wakikawa">
<organization></organization>
</author>
<date month="October" year="2009" />
</front>
<seriesInfo name="RFC5648"
value="" />
</reference>
<reference anchor="RFC4066">
<front>
<title>Candidate Access Router Discovery (CARD)</title>
<author fullname="M.Liebsch, A. Singh, H Chaskar, D. Funato and E. Shim" initials="M." surname="Liebsch">
<organization></organization>
</author>
<date month="July" year="2005" />
</front>
<seriesInfo name="RFC4066"
value="" />
</reference>
<reference anchor="RFC4067">
<front>
<title>Context Transfer Protocol (CXTP)</title>
<author fullname="J. Loughney, M. Nakhjiri, C. Perkins and R. Koodli" initials="J." surname="Loughney">
<organization></organization>
</author>
<date month="July" year="2005" />
</front>
<seriesInfo name="RFC4067"
value="" />
</reference>
<!-- Referred by Security Consideration
<reference anchor="individual.nsissid">
<front>
<title>NSIS Authentication, Authorization and Accounting Issues</title>
<author initials="H." surname="Tschofenig"
fullname="Tschofenig, H.">
<organization />
</author>
<date month="June" year="2003" />
</front>
<seriesInfo name="Internet Draft" value="draft-tschofenig-nsis-sid-00" />
<seriesInfo name="Work in progress" value="" />
</reference>
-->
<!-- Referred by Security Consideration
<reference anchor="individual.nsisaaa">
<front>
<title>NSIS Authentication, Authorization and Accounting Issues</title>
<author initials="H." surname="Tschofenig"
fullname="Tschofenig, H.">
<organization />
</author>
<date month="March" year="2003" />
</front>
<seriesInfo name="Internet Draft" value="draft-tschofenig-nsis-aaa-issues-01" />
<seriesInfo name="Work in progress" value="" />
</reference>
-->
</references>
<!-- End of Informative Reference -->
<section anchor="Appendix.A" title="">
<t>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.</t>
<t>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 <xref
target="fig.DCRN.UCRN"></xref></t>
<figure anchor="fig.DCRN.UCRN"
title="The topology for NSIS signaling in case of the route changes">
<preamble></preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
<!--End of Appendix.A -->
<!--End of Appendix -->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 23:03:41 |