RFC 5980
NSIS Protocol Operation in Mobile Environments
RFC 5980: NSIS Protocol Operation in Mobile Environments 🦋
Okay bestie, the title block is giving full cast 💅 Here's the tea:
- Authors: T. Sanda (Ed.) from Panasonic, X. Fu from University of Goettingen, S. Jeong from HUFS, J. Manner from Aalto University, and H. Tschofenig from Nokia Siemens Networks 🫶
- Category: Informational, so it's published for info purposes and is not an Internet Standards Track spec 🎀
- Date: March 2011 🌸
- ISSN: 2070-1721 ✨
- Obsoletes and updates: the title block doesn't list anything it obsoletes or updates 🧚
Abstract ✨
Okay so mobility of an IP-based node can change its routing paths, and that's lowkey a big deal 😭 It can seriously affect how the protocol operates and how state gets managed. This document talks about the effects mobility has on the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols work in different scenarios with mobility management protocols. Main character energy 👑
Status of This Memo 🌈
Quick heads up: this document is not an Internet Standards Track specification. It's published for informational purposes 💜
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🔥
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5980 🍓
Copyright Notice 🎀
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the publication date. Please read these carefully, bestie, because they describe your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. So without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation and Terminology . . . . . . . . . . . . 4
3. Challenges with Mobility . . . . . . . . . . . . . . . . . . . 5
4. Basic Operations for Mobility Support . . . . . . . . . . . . 8
4.1. General Functionality . . . . . . . . . . . . . . . . . . 8
4.2. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. NATFW NSLP . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Localized Signaling in Mobile Scenarios . . . . . . . . . 13
4.4.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 15
4.4.2. Localized State Update . . . . . . . . . . . . . . . . 15
5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 16
5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 17
5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 19
5.3. Interaction with Mobile IP Tunneling . . . . . . . . . . . 20
5.3.1. Sender-Initiated Reservation with Mobile IP Tunnel . . 20
5.3.2. Receiver-Initiated Reservation with Mobile IP
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3. CRN Discovery and State Update with Mobile IP
Tunneling . . . . . . . . . . . . . . . . . . . . . . 24
6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. NSIS Operation in the Multihomed Mobile Environment . . . 25
6.1.1. Selecting the Best Interface(s) or CoA(s) . . . . . . 26
6.1.2. Differentiation of Two Types of CRNs . . . . . . . . . 27
6.2. Interworking with Other Mobility Protocols . . . . . . . . 28
6.3. Intermediate Node Becomes a Dead Peer . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 301. Introduction 🦋
Mobility of IP-based nodes causes route changes, usually at the edge of the network. IP addresses are usually part of flow identifiers, so when an IP address changes, the flow identifier changes too. That's the General Internet Signaling Transport (GIST) message routing information, or Message Routing Information (MRI) [RFC5971]. Local mobility usually doesn't change the global IP addresses, but it does affect the routing paths inside the local access network 🌸
The NSIS protocol suite has two layers: the NSIS Transport Layer Protocol (NTLP) and the NSIS Signaling Layer Protocol (NSLP). GIST [RFC5971] implements the NTLP. It's independent of the signaling application and transports service-related info between neighboring GIST nodes 💅 Each specific service gets its own NSLP. Right now there are two specified NSLPs: the QoS NSLP [RFC5974] and the Network Address Translator / Firewall (NAT/FW) NSLP [RFC5973] ✨
The goals of this document are to show how mobility affects the NTLP and NSLPs, and to give guidance on how these NSIS protocols work in basic mobility scenarios. That includes Mobile IPv4 and Mobile IPv6 scenarios. It also shows how these protocols meet the mobility requirements set out in [RFC3726]. Overall, the NSIS protocols work really well in mobile environments 🔥 The Session ID (SID) used in NSIS signaling separates the signaling state from the IP addresses of the communicating hosts. So you can directly update signaling state in the network when mobility happens, without first tearing down the old state and then setting up a new one. That's the core reason NSIS signaling works so well when devices are on the move 🧚 The document also introduces additional info and mobility-specific enhanced operations, like the ones involving the crossover node (CRN) 🎀
This document focuses on basic mobility scenarios. Key management for handovers, multihoming, and interactions between NSIS and mobility management protocols other than Mobile IP are out of scope 🙈 Practical implementations also need various APIs across components within a node. API issues, like APIs from GIST to the various mobility and routing schemes, are out of scope too. The generic GIST API towards the NSLP is flexible enough to cover most mobility-related needs of the NSLP layer 💖
2. Requirements Notation and Terminology 💜
The terminology here is based on [RFC5971] and [RFC3753]. On top of that, the following terms are used. Heads up: in this document, a generic route change caused by regular IP routing is called a 'route change', and a route change caused by mobility is called 'mobility' 👑
(1) Downstream
The direction from a data sender towards the data receiver.
(2) Upstream
The direction from a data receiver towards the data sender.
(3) Crossover Node (CRN)
A Crossover Node is a node that, for a given function, is a merging point of two or more paths belonging to flows of the same session along which states are installed.
In mobility scenarios there are two different types of merging points in the network, depending on the direction of signaling flows followed by data flows. Here we assume that the Mobile Node (MN) is the data sender 🦋
- Upstream CRN (UCRN): the node closest to the data sender from which the state information in the direction from data receiver to data sender begins to diverge after a handover.
- Downstream CRN (DCRN): the node closest to the data sender from which the state information in the direction from the data sender to the data receiver begins to converge after a handover.
In general, the DCRN and the UCRN may be different because of the asymmetric characteristics of routing, even though the data receiver is the same 🌈
(4) State Update
State Update is the procedure for re-establishing NSIS state on the new path, tearing down NSIS state on the old path, and updating NSIS state on the common path due to mobility. The State Update procedure is used to address mobility for the affected flows 🍓
- Upstream State Update: State Update for the upstream signaling flow.
- Downstream State Update: State Update for the downstream signaling flow.
3. Challenges with Mobility 🦋
okay so this section is the tea on everything that goes wrong when mobility is involved 🫠. Mobility can mess with how the NSIS protocol suite runs, and bestie, you need to know these problems 💅
1. Change of route and possible change of the MN's IP address
Topology changes or network reconfiguration can send data packets to or from the MN down a different path, and it can even change the MN's IP address 😭. Normally a route change doesn't change the flow endpoints' addresses, but with mobility the address can change, and that messes with the path-coupled MRI because the source or destination address lives in there 🙈. So this affects GIST AND the NSLPs, like the packet classifier in the QoS NSLP or some rules in the NAT/FW NSLP. Firewall rules, NAT bindings, and QoS reservations that are already installed can go invalid because they point at a flow that doesn't exist anymore 💀. If the affected nodes are also on the new path, this information must be updated accordingly ✨.
2. Double state problem
After a handover, packets can get delivered over a brand new path 🛣️. The state on the old path is still sitting there after the state on the new path gets set up, so now there are two separate states for the same signaling session 👀. The old one gets deleted on its own through the soft state timeout, but that timer can be pretty long (e.g., 90 s as a default value) 😩. With the QoS NSLP, this can waste resources and make new reservations fail to get in because there isn't enough room ("lack of resources") 🥲. With the NAT/FW NSLP, the old installed state can still be reused after the MN roams somewhere new. That means another host could push data through a firewall without doing any NAT/FW NSLP signaling first, since the previous state hasn't expired yet 🚨.
3. End-to-end signaling and frequency of route changes
Route and IP changes in mobile environments happen way faster and more often than the usual route changes from a node or link failing 🏃♀️💨. So the NSLP state updates may need a speed boost ⚡.
4. Identification of the crossover node
When a handover happens at the edge of a network, usually only some parts of the end-to-end path used by the data packets change 🗺️. The crossover node (CRN) is the MVP here 👑. It manages setting up the new signaling application state, removes any useless state, and keeps the signaling localized to just the affected part of the network 🫶.
5. Upstream State Update vs. Downstream State Update
Internet routing is asymmetric, so the upstream and downstream paths are probably not exactly the same 🙃. That means state updates need to be handled independently for each direction 🔀.
6. Upstream signaling
If the MN is the receiver and moves to a new point of attachment, signaling upstream toward the Correspondent Node (CN) gets tricky 😵. New states have to be set up along the new path, but with a path-coupled Message Routing Method (MRM) that has to start in the downstream direction. So the MN can't start NTLP signaling state in the upstream direction, which means GIST can't easily send a Query upstream. There is an upstream Q-mode, but it only works in a limited scope 🥺. Other protocols, like application-level signaling (e.g., Session Initiation Protocol (SIP)) or mobility management signaling (e.g., Mobile IP), may help trigger NSLP and NTLP signaling from the CN side in the downstream direction ✨.
7. Authorization issues
State Update can be started by the MN, the CN, or even nodes inside the network, like the crossover node or the Mobility Anchor Point (MAP) in Hierarchical Mobile IP (HMIP) 🏰. When a State Update happens on behalf of the MN, it raises the question of who is actually allowed to make these state modifications 🔐.
8. Dead peer and invalid NSIS Receiver (NR) problem
When the MN is on the path of a signaling exchange, the old Access Router (AR) can't forward NSLP messages toward the MN after the handover 📭. The old AR's mobility or routing protocol (or even the NSLP) may trigger an error message saying the last node failed or the path got truncated 🚫. That error message gets forwarded and can mistakenly remove state on the existing common path if the state isn't updated before the error message propagates through the signaling peers 😱. This is called the 'invalid NSIS Receiver (NR) problem' 🎀.
9. IP-in-IP encapsulation
Mobility protocols may use IP-in-IP encapsulation on part of the end-to-end path to route traffic from the CN to the MN and back 🎁. Encapsulation makes it hard to identify and filter data traffic for things like a QoS reservation 🙈. It can also change routing paths, since the source and destination IP addresses of the inner header differ from those of the outer header. Mobile IP uses tunneling to forward data packets between end hosts 🚇. NSIS signaling messages are transparent on the tunneling path because the flow's addresses change. With Mobile IP tunneling, CRNs can be discovered on the tunneling path, which lets NSIS protocols do the State Update procedure over the IP tunnel 🤝. GIST then needs to cope with the change of Message Routing Information (MRI) for CRN discovery on the tunnel. NSLP signaling needs to figure out when to remove the tunneling segment on the signaling path and/or how to tear down the old state with the IP tunneling operation 🧩. Tunneling also adds an extra IP header as overhead that QoS NSLP has to account for, e.g., when resources need to be reserved 📦. So an NSLP usually has to know whether tunneling or route optimization is actually used for a flow [RFC5979] 💖.
4. Basic Operations for Mobility Support ✨
This section covers the basic operations of the NSIS protocol suite after mobility-related route changes 🌸. Details on how Mobile IP works with NSIS protocols come in the next section 🧚.
4.1. General Functionality
NSIS decouples state and flow identification 💜. A state is stored and referred to by the Session ID (SID), and the flows tied to a given NSLP state are defined by the Message Routing Information (MRI) 📚. GIST notices when the routing path associated with a SID changes and notifies the NSLP. It's then up to the NSLP to update the state in the network 🔄. So the effect is an update to the states, not a full new request 🙌. This decoupling also fixes a classic problem: some signaling protocols identify state by flow endpoints, so when those addresses change, the whole session state becomes invalid 😤.
Another benefit: if the MRI (the IP addresses associated with the data flow) stays the same after movement, NSIS signaling only repairs the affected path of the end-to-end session 🔧. So updating session info in the network is localized, and no end-to-end signaling will be needed ✨. If the MRI changes, end-to-end signaling usually can't be avoided, because new info for proper data flow identification has to reach all the way between the data sender and receiver. That's needed to update filters, QoS profiles, or other flow-related session data 📡.
GIST gives NSLPs an identifier of the next signaling peer, the Source Identification Information (SII) handle. When the SII-Handle changes, the NSLP knows a routing change has happened 🚦. The NSLP can also figure out whether it's the crossover node for the session. So CRN discovery is always done at the NSLP layer, because only NSLPs have a notion of end-to-end signaling 🕵️.
When a path changes, the session info on the old path needs to be removed. Normally that info is released when the session timer expires after a routing change ⏳. But the NSLP running on the end-host or the CRN, depending on the direction of the session, may use the SII-Handle (provided by GIST) to explicitly remove states on the old path. New session info is set up on the new path at the same time 🗑️➡️✨. Both current NSLPs use sequence numbers to identify the order of messages, and the protocols can use this info to recover from a routing change 🔢.
Since NSIS operates on a hop-by-hop basis, any peer can perform state updates 🤝. This works because a chain of trust is expected between NSIS nodes. If that weren't the case (e.g., true resource reservations are not possible), one misbehaving or compromised node would effectively break everything 😭. So currently the NSIS protocols don't limit the roles of each NSIS signaling peer on a path, and any node can make updates 🔓. Still, some updates are reflected back to the signaling endpoints, and they can decide whether the signaling actually succeeded 💌.
If the signaling packets are encapsulated in a tunnel, a separate signaling exchange is needed for the tunneled region. A binding is also needed to tie the end-to-end and tunneled session together 🎀.
In some cases the NSLP has to know whether tunneling is used, since the extra tunneling overhead has to be taken into account for things like resource reservations 🫶.
4.2. QoS NSLP
okay bestie, let's talk about QoS NSLP ✨ Figure 1 shows a Mobile IPv6 route optimization case where the data flows from the MN to the CN and the sender starts the reservation (sender-initiated) 💅
Once the MN notices a handover, it has to grab its new Care-of Address (CoA) and update the path coupled MRI so everything stays in sync 🦋 Then it sends a RESERVE message toward the CN 🚀 carrying the unique session ID, other identification info, and the reservation requirements (steps (1)-(4) in Figure 1). When a QoS NSLP node gets the RESERVE (the underlying NTLP is how those nodes get discovered 🧚), it sets up its QoS NSLP state and forwards the message toward the CN. If there's already NSLP state with that same session ID, it just gets updated. If every QoS NSLP node on the path supports the required QoS, the CN sends back a RESPONSE to confirm the reservation (steps (5)-(6) in Figure 1) 👑
In a bidirectional tunneling case, the only difference is that the RESERVE message should be sent to the home agent (HA) instead of the CN, and the node that responds with a RESPONSE should be the HA instead of the CN, too 🌸 More details are given in Section 5.
So for the basic operation there's no real difference between the different Mobile IP operation modes 🎀 The main thing for mobility support in NSIS is triggering NSLP signaling at the right moment, which is when a handover event is detected. Also, the destination of the NSLP signaling shall follow the Mobile IP data path, using path-coupled signaling 🫶
Now, the obsoleted state on the old path doesn't get explicitly released, because it can just expire on its timer 😭 To speed things up, it may be possible to localize the signaling. When the RESERVE message reaches a node (called CRN in this document, step (2) in Figure 1) where a state is determined for the first time to reflect the same session, that node may issue a NOTIFY message toward the MN's old CoA (step (9) in Figure 1). The QoS NSIS Entity (QNE) next to the MN's old position stops the NOTIFY message (step (10) in Figure 1) and sends a RESERVE message (with Teardown bit set) toward the CN to release the obsoleted state (step (11) in Figure 1). This RESERVE with tear message gets stopped by the CRN (step (12) in Figure 1) 💀 The Reservation Sequence Number (RSN) is included in the messages so the order of the signaling can be told apart. More details are given in Section 4.4
MN QNE1 MN QNE2 QNE3 QNE4 CN
(CoA1) | (CoA2) | (CRN) | |
| | | | | | |
| | |RESERVE | | | |
| | |------->| | | |
| | | (1) |RESERVE | | |
| | | |--------->| | |
| | | | (2) |RESERVE | |
| | | | |------->| |
| | | | | (3) |RESERVE |
| | | | | |------->|
| | | | NOTIFY| | (4) |
| | | |<---------| | |
| | | NOTIFY| (9) | | |
| |<------------| | | |
| | | (10) | | | |
| |RESERVE(T) | | | |
| |------------>| | | |
| | | (11) |RESERVE(T)| | |
| | | |--------->| | |
| | | | (12) | |RESPONSE|
| | | | | |<-------|
| | | | |RESPONSE| (5) |
| | | | RESPONSE|<-------| |
| | |RESPONSE|<---------| (6) | |
| | |<------ | (7) | | |
| | | (8) | | | |
| | | | | | |Figure 1: Example Basic Handover Signaling in the QoS NSLP 🍓
Further cases to consider are:
- receiver-initiated reservation if MN is sender
- sender-initiated reservation if MN is receiver
- receiver-initiated reservation if MN is receiver
In the first case, the MN can easily start a new QUERY along the new path after it moves, which installs signaling state and eventually pulls a new RESERVE out of the CN in the upstream direction ✨ The second and third cases need the CN to start a RESERVE or QUERY message instead. The tricky part in both is getting the CN to know the MN has moved 🙈 Since the MN is the receiver, it can't just use an NSLP message to tell it, because upstream signaling isn't possible in this case (cf. Section 3, Upstream Signaling).
4.3. NATFW NSLP
Figure 2 shows 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 from QoS NSLP is that for NATFW NSLP, only the NSIS initiator (NI) can update the signaling session, no matter what 🔥 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 sends a NATFW NSLP CREATE message toward the CN, carrying the unique session ID and other identification info for the session (steps (1)-(4) in Figure 2). When a NATFW NSLP node gets the CREATE message (the underlying NTLP discovers these nodes), it sets up the corresponding NATFW NSLP state and forwards the message toward the CN. If there's already an existing NSLP state with the same session ID, the state will be updated. If every NATFW NSLP node along the path accepts the required NAT/firewall configuration, the CN sends back a RESPONSE to confirm the configuration (steps (5)-(8) in Figure 2) 💜
In a bidirectional tunneling case, the only difference is that the CREATE message should be sent to the HA instead of the CN, and the node that responds with a RESPONSE should be the HA instead of the CN too 🦋
So for the basic operation there's no fundamental difference between the different Mobile IP operation modes 🌸 The main issue for mobility support in NSIS is triggering 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 ✨
Same deal with the old state here: it isn't explicitly released, because it can be released by timer expiration 😭 To speed things up, when the CREATE message reaches a node (called CRN in this document, step (2) in Figure 2) where a state is determined for the first time to reflect the same session, that node may issue a NOTIFY message toward the MN's old CoA (steps (9)-(10) in Figure 2). When the NI notices this, it sends a CREATE message toward the CN to release the obsoleted state (steps (11)-(12)) in Figure 2). 🎀
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) | | | |
| | | | | | |
| | | | | | |Figure 2: Example of NATFW NSLP Operation 👑
4.4. Localized Signaling in Mobile Scenarios ✨
Okay bestie, this section is all about the detailed CRN operations 🧚. Like we covered in the earlier sections, CRN operations are informational 💅.
Check out Figure 3 😭. Mobility basically makes the signaling path either converge or diverge, and which one happens depends on the direction each signaling flow is going 🦋.
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 the case that 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 the case that the MN is a data sender)
Note: OAR - old access router
NAR - new access router
Figure 3: The Topology for NSIS Signaling Caused by MobilityThese topological changes mean the NSIS state set up on the old path is no longer useful 💀. That state may be removed as soon as possible 🧹. Meanwhile, NSIS state needs to be established along the new path and updated along the common path 🛤️. The re-establishment of NSIS signaling may be localized when route changes (including mobility) occur. This keeps the impact on the service small and avoids 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 to only the affected portion of the signaling path, because the signaling path in the wireless access network usually changes only partially 📡.
4.4.1. CRN Discovery
The CRN is discovered at the NSLP layer 🔍. For QoS NSLP, when a RESERVE message with an existing SESSION_ID arrives and its SII and MRI have changed, the QNE knows that its upstream or downstream peer has changed because of the handover. That's the upstream peer for sender-oriented reservations and the downstream peer for receiver-oriented ones 🦋. The QNE also realizes that it is implicitly the CRN 👑.
4.4.2. Localized State Update
In the downstream State Update, the MN starts a RESERVE with a new RSN for state setup toward a CN. The implicit DCRN discovery also happens through the signaling procedure described in Section 4.4.1 🔥. The MRI from the DCRN to the CN (i.e., the common path) gets updated by that RESERVE message 💖. The DCRN may also send a NOTIFY with "Route Change" (0x02) to the previous upstream peer. That NOTIFY is forwarded hop-by-hop and reaches the edge QNE (i.e., QNE1 in Figure 1) 🚶♀️. Once the QNE is aware that the MN as QNI has disappeared (how this can be noticed is out of scope for NSIS, yet, e.g., GIST will eventually know this through undelivered messages), it sends a tearing RESERVE downstream 💨. When that tearing RESERVE reaches the DCRN, it stops forwarding and drops it 🛑. However, it is not necessary for GIST state to be explicitly removed, because GIST state maintenance is inexpensive [RFC5971] 🥰. Also, the sender-initiated approach leads to faster setup than the receiver-initiated approach, as in RSVP [RFC2205] ⚡.
In an upstream State Update, there are two possible methods 🤔. In the first, the CN (or the HA, Gateway Foreign Agent (GFA), or MAP) sends a refreshing RESERVE message toward the MN to perform the State Update when it gets a trigger (e.g., a Mobile IP (MIP) binding update). The UCRN is discovered implicitly through the CN-initiated signaling along the common path, as described in Section 4.4.1 🕵️♀️. When the refreshing RESERVE reaches the adjacent QNE of the UCRN, that QNE sends back a RESPONSE saying "Reduced refreshes not supported; full QSPEC required" (0x03). Then the UCRN sends a RESERVE with a full QSPEC toward the MN to set up a new reservation 🎀.
The UCRN may also send a tearing RESERVE to the previous downstream peer. That tearing RESERVE is forwarded hop-by-hop and reaches the edge QNE. Once the QNE is aware that the MN as QNI has disappeared, it drops the tearing peer 🫶. The second method works like this: if a GIST hop is already established on the new path (e.g., by a QUERY from the CN, or from the HA, GFA, or MAP) when the MN gets a hint from GIST that routing has changed, the MN sends a NOTIFY upstream saying "Route Change" (0x02) 📣. When that NOTIFY hits the UCRN, the UCRN knows the NOTIFY is for a known session and comes from a new SII-Handle 🧠. Then the UCRN sends a RESERVE with a new RSN and an RII toward the MN. When the MN receives that RESERVE, it replies with a RESPONSE 💌. The UCRN may also send a tearing RESERVE to the previous downstream peer. That tearing RESERVE is forwarded hop-by-hop and reaches the edge QNE. Once the QNE is aware that the MN as QNI has disappeared, it drops the tearing peer 🌸.
The State Update on the common path, which reflects the changed MRI, brings up issues for the end-to-end signaling addressed in Section 3 😬. Although the State Update over the common path doesn't trigger reprocessing of AAA and admission control, it may increase signaling overhead and latency ⏳.
One goal of the State Update is to avoid the double reservation on the common path, as described in Section 3 ✨. That double reservation problem can be solved by establishing a signaling association using a unique SID and by updating the packet classifier / MRI. In this case, even though the flows on the common path have different MRIs, they refer to the same NSLP state 🧚♀️💜.
5. Interaction with Mobile IPv4/v6 ✨
Okay so mobility management solutions like Mobile IP try to hide mobility effects from applications by providing stable addresses and avoiding address changes 🙈. The problem is that the MRI [RFC5971] contains flow addresses, so it changes whenever the CoA changes. That has an impact on some NSLPs, like QoS NSLP and NAT/FW NSLP 😤.
QoS NSLP must be mobility-aware, because it needs to care about the resources on the actual current path and send a new RESERVE or QUERY for the new path 🛣️. Applications running on top of Mobile IP communicate along logical flows that use home addresses. QoS NSLP, though, has to be aware of the actual flow path, e.g., whether the flow is currently tunneled or route-optimized 👀. QoS NSLP may also have to obtain current link properties. In particular, there may be extra overhead from mobility header extensions that must be accounted for in the QSPEC (e.g., the m parameter in the traffic model (TMOD); see [RFC5975]) 📦. Therefore, NSLPs must interact with mobility management implementations to request information about the current flow address (CoAs), source addresses, tunneling, or overhead 🫶. Furthermore, an implementation must select proper interface addresses in the natural language interface (NLI), so that a corresponding Messaging Association is established along the same path as the flow in the MRI 🧭. The home agent also needs to perform additional actions (e.g., reservations) for the tunnel. If the home agent lacks support for a mobility-aware QoS NSLP, a missing tunnel reservation is usually the result 🥲. Practical problems can occur when a home agent needs to send a GIST query (with S-flag=1) toward the MN's home address and that query isn't tunneled because of route optimization between HA and MN. In that case, the query will be wrongly intercepted by QNEs within the tunnel 🚨.
The NAT/FW box needs to be configured before MIP signaling, so NAT/FW signaling has to be performed to allow the Return Routability Test (RRT) and Binding Update (BU) / Binding Acknowledgement (BA) messages to traverse the NAT/FWs in the path 🚪. Once the RRT and BU/BA messages are complete, more NAT/FW signaling needs to be performed to pass the data 📬. An optimized version can include a combined NAT/FW message that covers both the RRT and BU/BA message pattern 💡. However, this may require the NAT/FW NSLP to receive a slight update so it can carry multiple NAT/FW rules in one signaling round trip 🔧.
This section analyzes NSIS operation with the tunneled route case, especially for QoS NSLP 🎀💅
5.1. Interaction with Mobile IPv4 🦋
okay so in Mobile IPv4 [RFC5944], data flows get forwarded using triangular routing 🔺, and an MN keeps a new CoA it gets from the Foreign Agent (FA) (or from an external method like DHCP) in the visited access network. when the MN is the data sender, the data and signaling flows it sends go straight to the CN 💌. they don't have to go through the HA, and they aren't necessarily sent indirectly through the HA using reverse tunneling either. flip it around, though, and when the MN is the data receiver, the data and signaling flows from the CN get routed through IP tunneling between the HA and the FA (or between the HA and the MN if it's using a co-located CoA) 🚇. so routing depends on the HA, and that means the NSIS protocols have to interact with Mobile IP's tunneling procedure for signaling. it's giving dependency, bestie 🥹
Figure 4 (a) to (e) shows how the NSIS signaling flows change depending on the direction of the data flows and the routing method 🗺️
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 CoA
CN HA (FL) MN
|IPv4(normal ) | | |
|-------------->| | |
| | MIPv4 (tunnel) | |
| |------------------------------->|
| | | |
(e) MIPv4: CN-->MN with co-located CoAFigure 4: NSIS Signaling Flows under Different Mobile IPv4 Scenarios
so when an MN (as the signaling sender) shows up at a new FA and the binding process is done (Figure 4 (a), (b), and (c)), the MN does the CRN discovery (DCRN) and the State Update toward the CN (like we talked about in Section 4) 🔄. that sets up the NSIS state along the new path between the MN and the CN ✨. if there's no reverse tunnel (Figure 4 (a)), the new NSIS state gets set up on the direct path from the MN to the CN. if the reverse tunnel and FA CoA are both in use (Figure 4 (b)), the new NSIS state gets set up along a tunneling path from the FA to the HA, separate from the end-to-end path 🧵. CRN discovery and State Update on the tunneling path also happen separately, if they're needed. and if the reverse tunnel and co-located CoA are used (Figure 4 (c)), the NSIS signaling for the DCRN discovery and the State Update is the same as the FA CoA case above, except the reverse tunneling path runs from the MN to the HA instead. so in this case, one of the tunnel endpoints is the MN, not the FA 💅
when an MN (as the signaling receiver) shows up at a new FA and the binding process is done (Figure 4 (d) and (e)), the MN sends a NOTIFY message to the signaling sender, which is the CN 📣. with the FA CoA (Figure 4 (d)), the CN starts NSIS signaling to update the existing state between the CN and the HA. after that, the NSIS signaling messages get forwarded to the FA and end up at the MN 🎯. a new NSIS state is set up along the tunneling path from the HA to the FA, separate from the end-to-end path. during this, a UCRN gets discovered on the tunneling path, and a new MRI for the State Update on the tunnel might need to be created 🆕. CRN discovery and State Update on the tunneling path also happen separately, if needed. with a co-located CoA (Figure 4 (d)), the NSIS signaling for the UCRN discovery and the State Update is also the same as the FA CoA case above, except the endpoint of the tunneling path from the HA is the MN 🫶
one more thing: Mobile IPv4 can optionally support route optimization 🏎️. if route optimization is supported, the signaling works the same way as Mobile IPv6 route optimization 💜
5.2. Interaction with Mobile IPv6 🌸
unlike Mobile IPv4, with Mobile IPv6 [RFC3775] the FA isn't required on the data path, and that's honestly so iconic 👑. when an MN moves to a visited network, it gets a CoA there, kind of like a co-located CoA in Mobile IPv4 🏠. on top of that, the route optimization process between the MN and the CN can be used to avoid the triangular routing that shows up in Mobile IPv4 scenarios 🙅♀️🔺
if route optimization isn't used, the data flow routing and NSIS signaling procedures (including the CRN discovery and the State Update) will look a lot like Mobile IPv4 with a co-located CoA 🪞. but if route optimization is used, signaling messages get sent directly from the MN to the CN, or from the CN to the MN, no detours 🏃♀️💨. so the route change procedures from Section 4 apply to this case too ✅
5.3. Interaction with Mobile IP Tunneling 🎀
in this section we're assuming the MN acts as an NI and the CN acts as an NR when Mobile IP and NSIS signaling are working together 🤝
scenarios for interacting with Mobile IP tunneling depend on a few things 🧐
- Whether a tunneling entry point (Tentry) is an MN or some other node. for a Mobile IPv4 co-located CoA or a Mobile IPv6 CoA, Tentry is an MN. for a Mobile IPv4 FA CoA, Tentry is an FA. in both cases, an HA is the tunneling exit point (Texit).
- Whether the QoS NSLP signaling mode is sender-initiated or receiver-initiated.
- Whether the operation mode over the tunnel uses preconfigured QoS sessions or dynamically created QoS sessions, as described in [RFC5979].
the following subsections describe sender-initiated and receiver-initiated reservations with Mobile IP tunneling, plus CRN discovery and State Updates with Mobile IP tunneling 📚💖
5.3.1. Sender-Initiated Reservation with Mobile IP Tunnel ✨
okay so this scenario assumes the FA is the Tentry 🎀 but if the MN and the FA count as the same node, the procedure is literally identical 💅
- When an MN moves into a new network attachment point, the QoS NSLP in the MN kicks off a
RESERVE(end-to-end) message to start the State Update procedure 🚀 The GIST sitting below the QoS NSLP adds its GIST header, then sends the encapsulatedRESERVEto the peer GIST node along with the matching QoS NSLP. Here the peer GIST node is an FA, as long as the FA is NSIS-aware 👀 The FA is one of the Mobile IP tunnel endpoints: the Tentry. For NSIS tunneling to work properly, a Mobile IP endpoint is required to be NSIS tunneling aware 🧚 If tunnel signaling comes from the FA, there are two possible scenarios, depending on whether the tunnel already has preconfigured QoS sessions. In the first case, the FA maps end-to-end QoS signaling requests straight onto the existing tunnel sessions. In the second case, the FA dynamically sets up and maintains tunnel QoS sessions, then links them to the matching end-to-end QoS sessions 🦋 [RFC5979]. - Figure 5 shows the typical NSIS operation over tunnels with preconfigured QoS sessions 🌸 Both the FA and the HA are configured with info about the Flow ID of the tunnel QoS session. When the FA gets a
RESERVEfrom the MN, it checks the tunnel QoS configuration and decides whether, and how, this end-to-end session can be mapped onto a preconfigured tunnel session. Then the FA tunnels theRESERVEto the HA. The CN replies with aRESPONSE, which arrives at the HA, the FA, and the MN ✨ - Figure 6 shows the typical NSIS operation over tunnels with dynamically created QoS sessions 🌈 When the FA receives an end-to-end
RESERVEfrom the MN, the FA picks the tunnel Flow ID, creates the tunnel session, and associates the end-to-end session with it. The FA then sends a tunnelRESERVE'message (matching the request of the end-to-end session) toward the HA to reserve tunnel resources. The tunnelRESERVE'is processed hop-by-hop inside the tunnel for the flow identified by the chosen tunnel Flow ID, while the end-to-endRESERVEpasses through the tunnel intermediate nodes (Tmid) 🍓 When both messages reach the HA, the HA creates the reservation state for the tunnel session and sends a tunnelRESPONSE'back to the FA. At the same time, the HA updates the end-to-endRESERVEbased on the result of the tunnel session reservation, then forwards it along the path toward the CN. When the CN receives the end-to-endRESERVE, it sends an end-to-endRESPONSEback to the MN 💖
More detailed operations are specified in [RFC5979] 📖
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE | |
| +--------------------------->| |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<---------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
Figure 5: Sender-Initiated QoS NSLP over Tunnel with Preconfigured
QoS Sessions
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
| | | | |
| RESERVE | | | |
+------------->| | | |
| | RESERVE' | | |
| +=============>| | |
| | | RESERVE' | |
| | +=============>| |
| | RESERVE | |
| +---------------------------->| |
| | | RESPONSE' | |
| | |<=============+ |
| | RESPONSE' | | |
| |<=============+ | |
| | | | RESERVE |
| | | +------------->|
| | | | RESPONSE |
| | | |<-------------+
| | RESPONSE | |
| |<----------------------------+ |
| RESPONSE | | | |
|<-------------+ | | |
| | | | |
Figure 6: Sender-Initiated QoS NSLP over Tunnel with Dynamically
Created QoS Sessions5.3.2. Receiver-Initiated Reservation with Mobile IP Tunnel 🦄
Figures 7 and 8 show examples of receiver-initiated operation over a Mobile IP tunnel, with preconfigured and dynamically created QoS sessions respectively 💜 The Basic Operation is the same as the sender-initiated case, so the vibes carry right over 🫶
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
| | | | |
| QUERY | | | |
+------------->| | | |
| | QUERY | |
| +--------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | RESERVE | |
| |<---------------------------+ |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +--------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
Figure 7: Receiver-Initiated QoS NSLP over Tunnel with Preconfigured
QoS Sessions
MN (Sender) FA (Tentry) Tmid HA (Texit) CN (Receiver)
| QUERY | | | |
+------------->| | | |
| | QUERY' | | |
| +=============>| | |
| | | QUERY' | |
| | +=============>| |
| | | RESPONSE' | |
| | |<=============+ |
| | RESPONSE' | | |
| |<=============+ | |
| | QUERY | |
| +---------------------------->| |
| | | | QUERY |
| | | +------------->|
| | | | RESERVE |
| | | |<-------------+
| | | RESERVE' | |
| | |<=============+ |
| | RESERVE' | | |
| |<=============+ | |
| | RESERVE | |
| |<----------------------------+ |
| | RESPONSE' | | |
| +=============>| | |
| | | RESPONSE' | |
| | +=============>| |
| RESERVE | | | |
|<-------------+ | | |
| RESPONSE | | | |
+------------->| | | |
| | RESPONSE | |
| +---------------------------->| |
| | | | RESPONSE |
| | | +------------->|
| | | | |
Figure 8: Receiver-Initiated QoS NSLP over Tunnel with Dynamically
Created QoS Session5.3.3. CRN Discovery and State Update with Mobile IP Tunneling ✨
okay so if a tunnel is in the mode of using dynamically created QoS sessions, the Mobile IP tunneling setup can have two kinds of CRNs 🫶: one on the end-to-end path and one on the tunneling path. if the tunnel is in the mode of using preconfigured QoS sessions, it can only have CRNs on end-to-end paths 🎀. the two paths handle CRN discovery and State Update independently, so no mixing them up, bestie 💅
CRN discovery for the end-to-end path starts when the MN sends a RESERVE (sender-initiated case) or QUERY (receiver-initiated case) message 🦋. the MN keeps using its HoA as the source address even after handover, so a CRN gets found through the normal route change process (same SID and Flow ID, but a different SII-Handle) 🔥. if the HA is QoS NSLP aware, the HA gets found as the CRN 👑. then the CRN kicks off the tearing-down process on the old path, as described in [RFC5974] 🧹
CRN discovery for the tunneling path is started by Tentry by sending a RESERVE' (sender-initiated case) or QUERY' (receiver-initiated case) message 🧚. the route change procedures in Section 4 apply to this case ✨
one more lowkey important thing 👀: the end-to-end state inside the tunnel should not be torn down until all the states inside the tunnel have been torn down from the implementation perspective. detailed discussions are out of scope for this document, so that's a later problem 🙈
6. Further Studies 🔮
all the sections above covered the basic issues of NSIS mobility support 💖. this section is the spicy preview 🌶️: it introduces potential issues and possible approaches for complicated scenarios in the mobile environment, namely peer failure scenarios, multihomed scenarios, and interworking with other mobility protocols. these may need to be resolved in the future 🌸. topics in this section are out of scope for this document, so the detailed operations here are just for future reference 📌
6.1. NSIS Operation in the Multihomed Mobile Environment 📱
in multihomed mobile environments, multiple interfaces and addresses (i.e., CoAs and HoAs) are available, so two major issues can be considered 🤔. the first is how to select or acquire the most appropriate interface(s) and/or address(es) from the end-to-end QoS point of view. the second is, when multiple paths are used simultaneously for load-balancing purposes, how to differentiate and manage two types of CRNs: the CRN between two ongoing paths (LB-CRN: Load Balancing CRN) and the CRN between the old and new paths caused by the MN's handover (HO-CRN: Handover CRN). this section introduces possible approaches for these issues 🦋
6.1.1. Selecting the Best Interface(s) or CoA(s) 💎
in the MIPv6 route optimization case, if registrations of multiple CoAs are provided [RFC5648], the contents of QUERYs sent by candidate CoAs can be used to select the best interface(s) or CoA(s) 🎯
assume that an MN is a data sender and has multiple interfaces 🙌. now the MN moves to a new location and acquires CoA(s) for multiple interfaces. after the MN performs the BU/BA procedure, it sends QUERY messages toward the CN through the interface(s) associated with the CoA(s). on receiving the QUERY messages, the CN or gateway determines the best (primary) CoA(s) by checking the 'QoS Available' object in the QUERY messages 👑. then a RESERVE message is sent toward the MN to reserve resources along the path that 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 the old access router (OAR) to release the reserved resources on the old path 🧹
for a 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 🫶
|--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 | | |
|<=================->|<===================->|<=============>|
| | | | | | | | |
Figure 9: Receiver-Initiated Reservation in the Multihomed
Environment6.1.2. Differentiation of Two Types of CRNs 🧩
when multiple interfaces of the MN are used simultaneously for load-balancing purposes, a possible approach for distinguishing the LB-CRN and HO-CRN is to introduce an identifier that determines the relationship between interfaces and paths 🔍
an MN uses interface 1 and interface 2 for the same session, where the paths (say path 1 and path 2) have the same SID but different Flow IDs, as shown in (a) of Figure 10 🎀. then one of the interfaces of the MN performs a handover and obtains a new CoA, and the MN will try to establish a new path (say Path 3) with the new Flow ID, as shown in (b) of Figure 10 🦋. in this case, the CRN between path 2 and path 3 cannot determine whether it is an LB-CRN or HO-CRN, since in both cases the SID is the same but the Flow IDs are different 😭. hence, the CRN will not know if State Update is required. one possible solution is to introduce a path classification identifier, which shows the relationship between interfaces and paths 💡. for example, signaling messages and QNEs that belong to paths from interface 1 and interface 2 carry the identifiers '00' and '02', respectively 🍓. by having this identifier, the CRN between path 2 and path 3 will be able to determine whether it is an LB-CRN or HO-CRN. for example, if path 3 carries '00', the CRN is an LB-CRN, and if '01', the CRN is an HO-CRN ✨
+--+ Path 1 +---+ +--+
| |IF1 <-----------------|LB-| common path | |
|MN| |CRN|-------------|CN|
| | Path 2 | | | |
| |IF2 <-----------------| | | |
| | +---+ +--+
| |
+--+
(a) NSIS Path classification in multihomed environments
+--+ Path 1 +---+ +--+
| |IF1 <-----------------|??-| common path | |
|MN| |CRN|-------------|CN|
| | Path 2 -| | | |
| |IF2 <--- +------+ | | | | |
| | \_|??-CRN|--v +---+ +--+
| | / +------+
+--+IF? <---
Path 3
(b) NSIS Path classification after handover
Figure 10: The Topology for NSIS Signaling in Multihomed Mobile
Environments6.2. Interworking with Other Mobility Protocols 🤝
in mobility scenarios, the end-to-end signaling problem caused by State Update (unlike the problem of generic route changes) leads to degraded 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 State Update is performed with scoped signaling messages within the access network under the MAP is for future study 🔭
in the interdomain handover, a possible way to mitigate the latency penalty is to use the multihomed MN 🌈. it is also possible to allow the NSIS protocols to interact with mobility protocols such as Seamoby protocols (e.g., Candidate Access Router Discovery (CARD) [RFC4066] and the Context Transfer Protocol (CXTP) [RFC4067]) and Fast Mobile IP (FMIP) 🧚. another scenario is to use a peering agreement that allows aggregation authorization to be performed for aggregate reservation on an interdomain link without authorizing each individual session 💜. how these approaches can be used in NSIS signaling is for further study 🌸
6.3. Intermediate Node Becomes a Dead Peer 💀
the failure of a (potential) NSIS CRN may result in incomplete state re-establishment on the new path and incomplete teardown on the old path after handover 😵. in this case, a new CRN should be rediscovered immediately by the CRN discovery procedure 🚨
the failure of an AR may make the interactions with Seamoby protocols (such as CARD and CXTP) impossible 🙃. in this case, the neighboring peer closest to the dead AR may need to interact with such protocols. a more detailed analysis of interactions with Seamoby protocols is left for future work 📝
in Mobile-IP-based scenarios, the failures of NSIS functions at an FA and an HA may result in incomplete interaction with IP tunneling 😬. in this case, recovery for NSIS functions needs to be performed immediately. in addition, a more detailed analysis of interactions with IP tunneling is left for future work 🔧
7. Security Considerations 🔐
this document does not introduce new security concerns 🛡️. the security considerations pertaining to the NSIS protocol specifications, especially [RFC5971], [RFC5973], and [RFC5974], 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 and CRNs. no unauthorized gatekeeping, no unauthorized state changes. this is a serious one, bestie 💀
8. Contributors 🫶
Sung-Hyuck Lee was the editor of early drafts of this document 🖊️. since draft version 06, Takako Sanda has taken over the editorship 👑
many individuals have contributed to this document 🌷. since it was not possible to list them all in the authors section, this section was created to have a sincere respect for those who contributed: Paulo Mendes, Robert Hancock, Roland Bless, Shivanajay Marwaha, and Martin Stiemerling 💖. separating the authors into two groups was done without treating any one of them better (or worse) than the others ⚖️
9. Acknowledgements 💖
the authors would like to thank Byoung-Joon Lee, Charles Q. Shen, Cornelia Kappler, Henning Schulzrinne, and Jongho Bang for significant contributions in early drafts of this document 🎀. 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 🌈
10. References 📚
okay bestie, these are the receipts 🧾✨ all the stuff this spec leans on, listed with every detail so you can go find it yourself 💜
10.1. Normative References 🔥
- [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC3775, June 2004.
- [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
- [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", RFC 5973, October 2010.
- [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010.
- [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
10.2. Informative References 🌸
these ones are the extra background reading, lowkey so worth a look 🦋
- [RFC2205] Braden, B., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC2205, September 1997.
- [RFC3726] Brunner, (Ed), M., "Requirements for Signaling Protocols", RFC3726, June 2004.
- [RFC3753] Manner, J., "Mobility Related Terminology", RFC3753, June 2004.
- [RFC4066] Liebsch, M., "Candidate Access Router Discovery (CARD)", RFC4066, July 2005.
- [RFC4067] Loughney, J., "Context Transfer Protocol (CXTP)", RFC4067, July 2005.
- [RFC5648] Wakikawa, R., "Multiple Care-of-Address Registration", RFC5648, October 2009.
- [RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.
- [RFC5979] Shen, C., Schulzrinne, H., Lee, S., and J. Bang, "NSIS Operation over IP Tunnels", RFC 5979, March 2011.
Authors' Addresses ✨
meet the squad who wrote this 🫶 contact info is all here, exactly as it's listed 💅
Takako Sanda (editor)
Panasonic Corporation
600 Saedo-cho, Tsuzuki-ku, Yokohama
Kanagawa 224-8539
Japan
Phone: +81 45 938 3056
EMail: sanda.takako@jp.panasonic.com
Xiaoming Fu
University of Goettingen
Computer Networks Group
Goldschmidtstr. 7
Goettingen 37077
Germany
Phone: +49 551 39 172023
EMail: fu@cs.uni-goettingen.de
Seong-Ho Jeong
Hankuk University of FS
Dept. of Information and Communications Engineering
89 Wangsan, Mohyun, Cheoin-gu
Yongin-si, Gyeonggi-do 449-791
Korea
Phone: +82 31 330 4642
EMail: shjeong@hufs.ac.kr
Jukka Manner
Aalto University
Department of Communications and Networking (Comnet)
P.O. Box 13000
FIN-00076 Aalto
Finland
Phone: +358 9 470 22481
EMail: jukka.manner@tkk.fi
URI: http://www.netlab.tkk.fi/~jmanner/
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo
02600
Finland
Phone: +358 50 4871445
EMail: Hannes.Tschofenig@nsn.com📦 where this page comes from
- ietf: rfc5980 2011-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms