NetExt Working Group C. Larsson Internet-Draft M. Eriksson Intended status: Standards Track P. Arvidsson Expires: September 5, 2009 Ericsson Research March 4, 2009 Simultaneous Multi-Access and Flow Mobility Support for PMIPv6 draft-larsson-netext-pmipv6-sma-flow-mobility-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 5, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Larsson, et al. Expires September 5, 2009 [Page 1] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Abstract This document specifies how flow mobility can be realized for a mobile node with multiple network interfaces, for which the network provides mobility support by means of Proxy Mobile IPv6 (PMIPv6). By introducing a "Primary Prefix", the mobile node is able to maintain IP data sessions when moving between different network interfaces. This document introduces a new set of ICMP and Mobility Header messages. It requires modifications of the mobile node. However, since support for simultaneous multi-access and flow mobility requires modifications of the mobile node anyway, the modifications suggested in this document are considered to be modest. The suggested enhancement is fully backwards compatible with the base Proxy Mobile IPv6 specification. The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack node. Larsson, et al. Expires September 5, 2009 [Page 2] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Allocation of Primary Prefix . . . . . . . . . . . . . . 7 3.2. Attaching additional network interfaces . . . . . . . . 8 3.3. Registration of Routing Rules . . . . . . . . . . . . . 9 3.4. Mobile Node movement . . . . . . . . . . . . . . . . . . 10 3.5. Sending packets to/from the Mobile Node . . . . . . . . 11 4. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 15 4.1. Acquiring Primary Prefix . . . . . . . . . . . . . . . . 15 4.2. Receiving Primary Prefix . . . . . . . . . . . . . . . . 15 4.3. Prefix and BID Binding Registration . . . . . . . . . . 15 4.4. Prefix and BID Binding Registration Acknowledgement . . 16 4.5. Sending/Receiving Routing Rule Update . . . . . . . . . 17 4.6. Sending/Receiving Routing Rule Update Acknowledgement . 17 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 19 5.1. Extensions to BUL Entry Data Structure . . . . . . . . . 19 5.2. Acquiring Primary Prefix . . . . . . . . . . . . . . . . 19 5.3. Receiving Primary Prefix . . . . . . . . . . . . . . . . 19 5.4. Relaying of Binding Registring between BID and Prefix . 20 5.5. Relaying Routing Rules Registration . . . . . . . . . . 20 5.6. Mobile Node De-registration . . . . . . . . . . . . . . 22 6. Local Mobility Agent Operation . . . . . . . . . . . . . . . . 23 6.1. Extensions to BC Entry Data Structure . . . . . . . . . 23 6.2. Recieving Proxy Primary Prefix Request . . . . . . . . . 23 6.3. Prefix and BID Binding Registration . . . . . . . . . . 23 6.4. Sending Proxy Primary Prefix Update . . . . . . . . . . 24 6.5. Registration of Routing Rules . . . . . . . . . . . . . 24 7. New ICMP and Mobility Header messages . . . . . . . . . . . . 25 7.1. New ICMP Messages . . . . . . . . . . . . . . . . . . . 25 7.1.1. ICMP Primary Prefix Request . . . . . . . . . . 25 7.1.2. ICMP Primary Prefix Acknowledgement . . . . . . 26 7.1.3. ICMP Primary Prefix Binding Update . . . . . . . 27 7.1.4. ICMP Primary Prefix Binding Acknowledgement . . 29 7.1.5. ICMP Routing Rules Update . . . . . . . . . . . 30 7.1.6. ICMP Routing Rules Acknowledgement . . . . . . . 31 7.2. New Mobility Header Messages . . . . . . . . . . . . . . 32 7.2.1. Proxy Primary Prefix Request Message . . . . . . 32 7.2.2. Proxy Primary Prefix Acknowledgement Message . . 34 7.2.3. Proxy Primary Prefix BU Message . . . . . . . . 35 7.2.4. Proxy Primary Prefix BA Message . . . . . . . . 37 7.2.5. Proxy Primary Prefix Update Message . . . . . . 38 7.2.6. Proxy Primary Prefix Update Ack Message . . . . 39 7.2.7. Proxy Routing Rules Update Message . . . . . . . 40 Larsson, et al. Expires September 5, 2009 [Page 3] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 7.2.8. Proxy Routing Rules Ack Message . . . . . . . . 42 8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 11.1. Normative References . . . . . . . . . . . . . . . . . . 47 11.2. Informative References . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Larsson, et al. Expires September 5, 2009 [Page 4] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 1. Introduction Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to a PMIPv6 domain through multiple network interfaces. When the multi- interfaced mobile node connects to the PMIPv6 domain, the Local Mobility Anchor (LMA) must allocate a new mobility session for each of the attached interfaces. The LMA may allocate more than one home network prefix for a given interface of the mobile node. All the prefixes associated with a given interface must be managed as part of one mobility session, associated with that interface. The PMIPv6 specification does not specify how to maintain sessions that must survive loss of network connectivity. A typical scenario is when a user has a laptop with both WLAN and 3GPP network interfaces. Multiple IP data sessions have been established, some of the sessions over WLAN and the remaining sessions over 3GPP. When the user moves out of WLAN coverage, sessions initiated over the WLAN access will be terminated according to PMIPv6. Another example would be that the user in the previous scenario remains within the WLAN coverage, but due to traffic congestion over the WLAN access either the mobile node or the network decides to move some or all data sessions from the WLAN to the 3GPP access network. The above examples are just two examples when support for simultaneous multi-access and flow mobility would be beneficial for the end user and the network operator. One potential solution to the above problems is to implement Mobile IPv6 (MIPv6) in the mobile node, as described in [RFC3775]. However, when there are reasons for not implementing a mobility management solution in the mobile node, the solution described in this specification is preferable. Larsson, et al. Expires September 5, 2009 [Page 5] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 2. Conventions and Terminology 2.1. Conventions In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Terminology All the general mobility-related terms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC3775] and the Proxy Mobile IPv6 base specification [RFC5213]. This document frequently uses the following terms: Primary Prefix A network prefix which allows simultaneous use of multiple accesses and flow mobility. It is bound to a virtual interface, and Routing Rules are used to place flows on available physical interfaces. Routing Rules Rules that control over which available physical interface each primary prefix flow is transferred. Larsson, et al. Expires September 5, 2009 [Page 6] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 3. Overview To facilitate simultaneous multi-access and flow mobility, an additional prefix, the so called "Primary Prefix", is allocated to the mobile node. An address derived from the Primary Prefix is used as permanent IP address for applications to bind their sockets to. Applications that must sustain partial loss of network connectivity should use an address derived from this Primary Prefix. Simultaneous multi-access and flow mobility implies that there must exist functionality in the mobile node that can decide how different data flows should be sent over available network interfaces. A session can be identified by several parameters. In [I-D.larsson-mext-flow-distribution-rules], a set of parameters for identifying sessions are defined. All parameters needed to identify a session constitute a so called Routing Rule. Additionally, [I-D.larsson-mext-flow-distribution-rules] explains how each routing rule is associated with a BID. How routing rules are generated and how the associations between BIDs and Home Network Prefixes are created is outside the scope of this document. This document assumes that this information is available and explains how to make use of it. To achieve simultaneous multi-access and flow mobility, some modifications to the mobile node are required. This specification enables the mobile node to request a Primary Prefix and to establish, for each Home Network Prefix assigned to the mobile node, a binding to a unique Binding Identifier (BID) [I-D.ietf-monami6-multiplecoa]. It also allows either the mobile node or the network (via the LMA) to update the routing rules required for simultaneous multi-access and flow mobility. Finally, it allows the network to update Mobile Access Gateways about the mobile node's Primary Prefix to ensure that packet forwarding between the LMA and the mobile node is working properly. 3.1. Allocation of Primary Prefix A mobile node with support for simultaneous multi-access sends a request to the access network asking for a Primary Prefix. If the network is a PMIP enabled network, the MAG, when receiving the ICMP Primary Prefix Request, sends a "Proxy Primary Prefix Request" to the LMA asking for a Primary Prefix to be allocated to the mobile node. Upon receiving the Proxy Primary Prefix Request the LMA allocates the Primary Prefix and creates a new Binding Cache entry for the Primary Prefix. The LMA then sends a "Proxy Primary Prefix Acknowledgement" back to the MAG. Upon receiving the "Proxy Primary Prefix Acknowledgement" the MAG updates its Binding Update List entry. Larsson, et al. Expires September 5, 2009 [Page 7] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Additionally, it ensures that packets with a source address derived from the Primary Prefix arriving from the mobile node are accepted and tunneled towards the LMA. The MAG will also accept and forward packets from the LMA to the mobile node in which the destination address of the inner packet is inside the Primary Prefix. The MAG sends an "ICMP Primary Prefix Acknowledgement" back to the mobile node. Once the mobile node receives the acknowledgement the prefix is allocated to a "virtual interface". Addresses derived from the Primary Prefix are then used for sessions that needs to sustain movement between different physical network interfaces. The Home Network Prefix, allocated as described in [RFC5213], can still be used, but these sessions can not be moved between different physical network interfaces. MN MAG LMA | | | |-------->| | 1. ICMP Primary Prefix Request | | | | |------->| 2. Proxy Primary Prefix Request | | | | |<-------| 3. Proxy Primary Prefix Acknowledgement | | | |<--------| | 4. ICMP Primary Prefix Acknowledgement | | | Figure 1: Allocation of Primary Prefix 3.2. Attaching additional network interfaces As the mobile node attaches new interfaces to the PMIPv6 domain, each interface is assigned a new set of prefixes according to [RFC5213]. According to [I-D.ietf-monami6-multiplecoa] a multi-homed node that registers multiple care-of addresses to the same HoA must associate each new CoA with a unique BID. The analogue is true for a mobile node with support for flow mobility, but instead of using the CoA the Home Network Prefixes assigned to the network interface are used. Consequently, the mobile node will send information about the current binding between the Home Network Prefix and the BID to the LMA. In Mobile IPv6, the binding between the BID and the CoA is associated with the Home Address. In this case, the association between the BID and the Home Network Prefix is instead associated with the Primary Prefix. When a mobile node decides to register a binding between a BID and a Home Network Prefix, it allocates a BID for the Home Network Prefix Larsson, et al. Expires September 5, 2009 [Page 8] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 and sends a request to the LMA (via the MAG) with the binding information. The MAG forwards the message to the LMA, which establish the required binding between the BID and the Home Network Prefix. Information about the binding is stored in the Binding Cache Entry for the Primary Prefix. The LMA then acknowledge the request and indicates the status of the binding request in the reply. Upon receiving the acknowledgement from the LMA, the MAG ensures that it accepts packets using the Primary Prefix in the same way as packets using the Home Network Prefix. I.e., the MAG ensures that packets, with a source address derived from the Primary Prefix, arriving from the mobile node are accepted and tunneled towards the LMA. The MAG will also accept and forward packets from the LMA to the mobile node in which the destination address of the inner packet is inside the Primary Prefix. The MAG finally acknowledge the request back to the mobile node. MN MAG LMA | | | |-------->| | 1. ICMP Primary Prefix Binding Update | | | | |------->| 2. Proxy Primary Prefix Binding Update | | | | |<-------| 3. Proxy Primary Prefix Binding Acknowledgement | | | |<--------| | 4. ICMP Primary Prefix Binding Acknowledgement | | | Figure 2: Attaching additional network interfaces 3.3. Registration of Routing Rules How the flows are sent over the different physical interfaces can be decided either by the network or in the mobile node. According to [I-D.larsson-mext-flow-distribution-rules], each routing rule is associated with a BID. The current active set of routing rules must be known by both the network (LMA) and the mobile node. If the mobile node creates the routing rules, the Routing Rules Update message is initiated from the mobile node and the sequence diagram is as depicted below. At the LMA the Routing Rules are stored in the Binding Cache entry for the Primary Prefix. Larsson, et al. Expires September 5, 2009 [Page 9] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 MN MAG LMA | | | |-------->| | 1. ICMP Routing Rules Update | | | | |------->| 2. Proxy Routing Rules Update | | | | |<-------| 3. Proxy Routing Rules Acknowledgement | | | |<--------| | 4. ICMP Routing Rules Acknowledgement | | | Figure 3: Mobile node initiating Routing Rules Update Once the LMA has accepted the routing rules, a "Proxy Routing Rules Acknowledgement" is sent back to the MAG. The MAG does not store any information about the Routing Rules. It only holds information about the Primary Prefix for the mobile node. The MAG forwards the acknowledgement from the LMA to the mobile node. If the Routing Rules update message was successful, the mobile node can start to forward the packets accordingly. In case of an unsuccessful Routing Rules Update, the flows will remain on existing network interfaces. If the network creates the routing rules, the Routing Rules Update message is initiated from the LMA and the sequence diagram is as depicted below. At the LMA, the Routing Rules are stored in the Binding Cache Entry for the Primary Prefix. MN MAG LMA | | | | |<-------| 1. Proxy Routing Rules Update | | | |<--------| | 2. ICMP Routing Rules Update | | | |-------->| | 3. ICMP Routing Rules Acknowledgement | | | | |------->| 4. Routing Rules Acknowledgement | | | Figure 4: LMA initiating Routing Rules Update 3.4. Mobile Node movement As the mobile node moves to a new MAG in the PMIPv6 domain this is a movement that is transparent for the mobile node. Hence, if the mobile node has allocated a Primary Prefix this information must also be known by the new MAG to ensure that it can route packets to/from Larsson, et al. Expires September 5, 2009 [Page 10] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 the mobile node. The new MAG sends a Proxy Binding Update according to [RFC5213]. the LMA, when processing the PBU, looks into its Binding Cache to see if a Primary Prefix has been allocated to this mobile node. If this is the case the LMA includes a Primary Prefix option in the PBA sent to the MAG. If no Primary Prefix has been allocated to the mobile node then an ordinary PBA according to [RFC5213] is sent to the MAG. Upon receiving the PBA from the LMA the MAG ensures that it accepts packets using the Primary Prefix in the same way as packets using the Home Network Prefix. I.e., the MAG ensures that packets, with a source address derived from the Primary Prefix, arriving from the mobile node are accepted and tunneled towards the LMA. The MAG will also accept and forward packets from the LMA to the mobile node in which the destination address of the inner packet equals the Primary Prefix. MN MAG LMA | | | |-------->| | 1. MN attaches to a new MAG | | | | |------->| 2. PBU | | | | |<-------| 3. PBA (incl. Primary Prefix option) | | | | | | Figure 5: New MAG learns Primary Prefix 3.5. Sending packets to/from the Mobile Node To explain how traffic is sent from and to a mobile node, a scenario is drawn with the following assumptions: o The mobile node has two active network interfaces, interface 1 (IF1) connected to MAG1 and interface 2 (IF2) connected to MAG2. o Home Network Prefix 1 (HNP1) has been allocated to IF1 and Home Network Prefix 2 (HNP2) has been allocated to IF2. o Since this mobile node has support for simultaneous multi-access and flow mobility, it has requested and successfully been allocated a Primary Prefix (PP). This Primary Prefix is typically allocated to a virtual interface and used by applications when connecting to a socket. Larsson, et al. Expires September 5, 2009 [Page 11] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 o A set of Routing Rules with associated Binding Identifiers and the relation between each Home Network Prefix and BID have been created, either by the mobile node or the network. The actual procedure for creating these relations are outside the scope of this document. This information has been stored both at the mobile node and in the LMA. How this information is transferred between the mobile node and the LMA is described in Sections 3.2 and 3.3. List of Routing Rules: Routing Rule A <--> BID1 Routing Rule B <--> BID2 Relation between BID and Home Network Prefix: BID1 <--> HNP1 BID2 <--> HNP2 o The Mobile Node (MN) is communicating with a Correspondent Node (CN). The below figure outlines the described example. There exist a set of routing rules, each one associated with a BID, and a binding list describing how each Home Network Prefix is associated with a BID. In the LMA, this information is stored with the Primary Prefix. How this information is stored in the mobile node is implementation dependent and outside the scope of this document. Larsson, et al. Expires September 5, 2009 [Page 12] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 +----+ | CN | +----+ | LMA Binding Cache: | ================== +-------+ MN-ID: HNP1; ... | LMA | MN-ID: HNP2; ... +-------+ MN-ID: PP; / \ Routing Rule A <--> BID1; / \ Routing Rule B <--> BID2; / \ HNP1 <--> BID1; / \ HNP2 <--> BID2; +------+ +------+ | MAG1 | | MAG2 | +------+ +------+ \ / \ / \ / +-----------+ IF1: HNP1 | IF1 | IF2 | IF2: HNP2 +-----+-----+ | PP | +-----------+ Mobile Node Figure 6: Network When the mobile node sends a packet to the CN, the source address of the packet is an address derived from the Primary Prefix and the destination address is the address of the CN. As the mobile node processes the outgoing packet, it will get a match on one of the routing rules. This Routing Rule is associated with a BID, which in turn is associated with a Home Network Prefix assigned to one of the physical network interfaces. At this stage, the mobile node knows on which interface to send the packet and it transmits the packet on this interface. The MAG receiving the packet recognizes the prefix of the source address as the Primary Prefix and tunnels the packet towards the same LMA as it would have done for any of the Home Network Prefixes advertised on this link. When the LMA receives the tunneled packet, it decapsulates it and routes it towards the CN. When an LMA receives a packet from a CN, it will search the Binding Cache for an entry. In this specific case, this entry will be an Larsson, et al. Expires September 5, 2009 [Page 13] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 entry holding the Primary Prefix. The LMA matches the incoming packet against the Routing Rules stored in the found BC entry. As a result of this matching a Routing Rule is found. This Routing Rule is associated with a BID, which in turn is associated with a Home Network Prefix. The Binding Cache entry for the Home Network Prefix holds all information required for tunneling the packet towards the MAG. When the MAG receives the tunneled packet, it decapsulates it and verifies that the prefix in the destination address is inside the Primary Prefix of the mobile node. It then forwards the packet to the mobile node. Larsson, et al. Expires September 5, 2009 [Page 14] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 4. Mobile Node Operation This section defines the mobile node operation. 4.1. Acquiring Primary Prefix When a mobile node decides that it has a need for simultaneous multi- access it will start the procedure of acquiring a Primary Prefix. This decision is typically made by either the user or an automated access selection system, but exactly how is outside the scope of this document. The following steps MUST be taken by the mobile node in order to initiate the Primary Prefix Acquiring process. o The mobile node MUST construct an ICMP Primary Prefix Request message. In this message the mobile node MUST set the HNP field to a valid HNP that it earlier received from the network. The value of the BID MUST be set by the mobile node to a value that it want to identify the binding between the HNP and Primary Prefix. The sequence number field must be set to a valid sequence number. o The mobile node MUST send this message to the next hop router on the access where the HNP set in the message is configured. 4.2. Receiving Primary Prefix On receiving a ICMP Primary Prefix Acknowledgment a mobile node MUST process the message as described below. o The mobile node MUST verify that the message received is a response to a previously sent ICMP Primary Prefix Request. This done by comparing the HNP and sequence number fields with the fields stored when sending the message. If the values does not match the mobile node MUST NOT proceed with any of the steps listed below. o The mobile node MUST create a virtual interface (or equivalent) to which it sets an address generated from the Primary Prefix received. It MUST also set up the local binding between the Primary Prefix and the HNP. This binding will be identified by the BID. 4.3. Prefix and BID Binding Registration Generally, there is no requirement for the mobile node to use SMA support in order to provide backwards compatibility with the PMIPv6 [RFC5213]. In the case such decision is taken by a mobile node, MN will initiate procedure described in Section XXX. This procedure will result in a single binding of one of HNP used for sending Larsson, et al. Expires September 5, 2009 [Page 15] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Primary Prefix Request message. Later on a mobile node MAY decide to create bindings for other interfaces in the MN. This may happen due to the fact that new interfaces will be configured in the MN, which did not exist before. Another example is that MN did not have many flows active simultaneously and there were no need to send them through different interfaces. If mobile node sends ICMP Primary Prefix BU message: o it MUST set the HNP field to a valid HNP that it earlier received from the network. The value of the BID MUST be set by the mobile node to a value that it want to identify the binding between the HNP and Primary Prefix. The sequence number field must be set to a valid sequence number o The mobile node MUST send this message to the next hop router on the access where the HNP set in the message is configured. 4.4. Prefix and BID Binding Registration Acknowledgement Upon receiving ICMP Primary Prefix BA message, MN MUST verify the following: o The message received is a response to a previously sent ICMP Primary Prefix BU. This done by comparing the HNP and sequence number fields with the fields stored when sending the message. If the values does not match the mobile node MUST NOT proceed with any of the steps listed below. o The mobile node MUST verify the status code of the received message. If status code indicates success of the operation, mobile node MUST update its binding cache with the correspondent BID and HNP values. o Mobile node MUST verify if the current Routing Rules set is consistent with the acknowledged Primary Prefix BU message. o If the Routing Rules set not consistent with the currently established bindings, the mobile node MUST initiate procedure for Routing Rules update. In the case, ICMP Primary Prefix BA message indicate failure of operation, the mobile node SHOULD make an attempt to retransmit the ICMP Primary Prefix BU message. The recommended number of retransmissions is TBD. Larsson, et al. Expires September 5, 2009 [Page 16] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 4.5. Sending/Receiving Routing Rule Update This document assumes that Routing Rules [I-D.larsson-mext-flow-distribution-rules, I-D.eriksson-mext-mipv6-routing-rules] can be sent bidirectionally, i.e. by mobile node, due to changes of policies or interfaces availability in mobile node, or by LMA, due to changes of policies at the network side. The Routing Rules update message exchange is identical in either direction. Bindings updates and Routing Rules exchange between mobile nodes and LMA is entirely decoupled and does not necessarily require both updates following each other. The reason for that is access selection policies control over what kind of update and when this update should take place. For example, if a mobile node or network makes a decision of moving a flow from one interface to another, there is no need for binding update, because BIDs and HNPs are not changed. The Routing Rules update procedure should take place only if there are no any conditional rules [I-D.larsson-mext-flow-distribution-rules, I-D.eriksson-mext-mipv6-routing-rules] specified earlier, or there are no any rules at all, which will conduct flows appropriately. On the other hand, if, for example, one of interfaces will be de- configured in the mobile host, and there were no traffic going through that interface, there is no need to change Routing Rules. Rather only bindings have to be synchronized between mobile node and LMA. Mobile node MUST NOT send Routing Rules Update messages if there is no any Primary Prefix configured in the mobile node. Mobile node MUST send Routing Rules Update message whenever it discovers inconsistency between currently installed bindings and routing rules. An ICMP message is used for this purpose, see Section XXX. Routing Rules are associated with a host,independently on how many interfaces are active in the host. Thus, along with the Routing Rules, the mobile node MUST send a Primary Prefix, which will be associated with the Routing Rules. 4.6. Sending/Receiving Routing Rule Update Acknowledgement Upon receiving ICMP Routing Rules Update Ack message, mobile node MUST verify that the sequence number in this message corresponds to the one sent in ICMP Routing Rules Update message. Mobile node MUST examine the status code in the ICMP Routing Rules Update Ack message. If the status code indicates success, the mobile node will continue its operation as normal, i.e. keep flow distribution among interfaces according to the latest updates of BIDs and RRs. If status code Larsson, et al. Expires September 5, 2009 [Page 17] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 indicates failure, mobile node SHOULD start retransmission of ICMP Routing Rules Update message. The recommended number of retransmissions is TBD. If mobile node fails to update Routing Rules, it MUST fail over to any (up to mobile node) consistent combination of interfaces bindings and Routing Rules set. Larsson, et al. Expires September 5, 2009 [Page 18] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 5. Mobile Access Gateway Operation This section explains the mobile access gateway operation. 5.1. Extensions to BUL Entry Data Structure As described in Section 6.1 of [RFC5213] every Mobile Access Gateway MUST maintain a Binding Update List. Each entry in this list represents a mobile node's mobility binding with its Local Mobility Anchor. To support this specification the Binding Update List entry data structure MUST be extended with the following fields: Primary Prefix A list of Primary Prefixes of the mobile node. 5.2. Acquiring Primary Prefix On receiving a ICMP Primary Prefix Request the Mobile Access Gateway MUST process the message as specified below. o The Mobile Access Gateway MUST construct a Proxy Primary Prefix Request message. This message MUST contain the HNP and BID fields set to the value of the corresponding fields of the received ICMP Primary Prefix Request. The message MUST also contain the MN-ID from the BUL entry associated with this mobile node. o The Mobile Access Gateway MUST send the message constructed to the IPv6 address of the Local Mobility Anchor that is contained in the BUL entry associated with this mobile node. 5.3. Receiving Primary Prefix On receiving a Proxy Primary Prefix Acknowledgement a Mobile Access Gateway MUST process the message as specified below. o The Mobile Access Gateway MUST read the Primary Prefix field of the received message and set up its ingress filter so that any packet from the Primary Prefix can pass. It MUST also set up tunneling for the Primary Prefix to the Local Mobility Anchor and add it to the list of Primary Prefixes in the BUL entry corresponding to the mobile node. o The Mobile Access Gateway MUST send a ICMP Primary Prefix Acknowledgement message to the mobile node's link local address. This message MUST contain the Primary Prefix, HNP, BID and sequence number received in the Primary Prefix Binding Acknowledgement. Larsson, et al. Expires September 5, 2009 [Page 19] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 5.4. Relaying of Binding Registring between BID and Prefix On receiving an ICMP Primary Prefix Binding Update Request a Mobile Access Gateway MUST process the message as specified below. o The Mobile Access Gateway MUST construct a Proxy Primary Prefix Binding Update message. It MUST set the BID, HNP Primary Prefix and sequence number fields of this message to the values of the corresponding fields in the received ICMP Primary Prefix Request. The MN-ID field of the Proxy Primary Prefix Binding Update message MUST be set to the value of the MN-Identifier found in the corresponding BUL entry. o The Mobile Access Gateway MUST send the message constructed to the IPv6 address of the Local Mobility Anchor that is contained in the BUL entry associated with this mobile node. On receiving an Proxy Primary Prefix Binding Update Response a Mobile Access Gateway MUST process the message as specified below. o The Mobile Access Gateway MUST read the Primary Prefix field of the received message and set up its ingress filter so that any packet from the Primary Prefix can pass. It MUST also set up tunneling for the Primary Prefix to the Local Mobility Anchor and add it to the list of Primary Prefixes in the BUL entry corresponding to the mobile node. o The Mobile Access Gateway MUST add the Primary Prefix received to the Primary Prefix field of the corresponding BUL entry. If the Primary Prefix is already in the list it should not be added. o The Mobile Access Gateway MUST setup its ingress filter so that it allows packets sent from the Primary Prefix to be received and forwarded on the interface that the mobile node is connected to. o The Mobile Access Gateway MUST send a ICMP Primary Prefix Binding Acknowledgement message to the mobile node's link local address. This message MUST contain the sequence number and the status field received in the Primary Prefix Binding Update Response. 5.5. Relaying Routing Rules Registration On receiving an ICMP Routing Rules Update Request a Mobile Access Gateway MUST process the message as specified below. o The Mobile Access Gateway MUST construct a Proxy Routing Rules Update message. It MUST set the Primary Prefix and sequence number fields of this message to the values of the corresponding Larsson, et al. Expires September 5, 2009 [Page 20] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 fields in the received ICMP Primary Prefix Request. It MUST also copy the Routing Rules payload of the received message to the Routing Rules payload field of the newly constructed message. The MN-ID field of the Primary Prefix Binding Update message MUST be set to the value of the MN-Identifier field found in the corresponding BUL entry. o The Mobile Access Gateway MUST send the message constructed to the IPv6 address of the Local Mobility Anchor that is contained in the BUL entry associated with this mobile node. On receiving a Proxy Routing Rules Acknowledgment a Mobile Access Gateway MUST process the message as specified below. o The Mobile Access Gateway MUST send a ICMP Routing Rules Update Acknowledgement message to the mobile node's link local address. This message MUST have the sequence number and the status field set to the values received in the Proxy Routing Rules Update Acknowledgment. It MUST also copy the Routing Rules payload of the received message to the Routing Rules payload field of the newly constructed message. On receiving a Proxy Routing Rules Update Request a Mobile Access Gateway MUST process the message as specified below. o The Mobile Access Gateway MUST construct a ICMP Routing Rules Update message. It MUST set the Primary Prefix and sequence number fields of this message to the values of the corresponding fields in the received ICMP Primary Prefix Request. It MUST also copy the Routing Rules payload of the received message to the Routing Rules payload field of the newly constructed message. o The Mobile Access Gateway MUST send the message constructed to the link local address of the mobile node that is contained in the BUL entry associated with this mobile node. On receiving a ICMP Routing Rules Acknowledgment a Mobile Access Gateway MUST process the message as specified below. o The Mobile Access Gateway MUST send a Proxy Routing Rules Update Acknowledgement message to the IPv6 address of the Local Mobility Anchor. This message MUST have the sequence number and the status field set to the values received in the Proxy Routing Rules Update Acknowledgment. It MUST also MN-ID field set to the value of MN- Identifier field from the corresponding BUL entry. Larsson, et al. Expires September 5, 2009 [Page 21] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 5.6. Mobile Node De-registration When a Mobile Node moves away from a domain handled by a specific MAG and moves to another MAG this will trigger the MAG to de-register the Mobile Node from the LMA. When this is done, the MAG will remove its BUL entry for the Mobile Node. This MUST trigger the following procedure in the MAG. o For every Primary Prefix in the Primary Prefix list the MAG MUST remove any ingress filtering exceptions and tunnel state set up for this address. Larsson, et al. Expires September 5, 2009 [Page 22] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 6. Local Mobility Agent Operation This section defines the local mobility anchor operation. 6.1. Extensions to BC Entry Data Structure In addition to binding cache entries specified in [RFC5213] LMA, supporting simultaneous multi-access operation, must create a binding cache entry for the primary prefix allocated for the MN. This entry must contain at least one BID mapped to the MN's care-of-address. The actual binding contains in the Proxy Primary Prefix Request: BID assigned to the care-of-address, which will be received by LMA in Primary Prefix Allocation Request message. Once BC entry for Primary Prefix allocated, LMA MUST insert references into this BC entry when new Proxy Primary Prefix BU messages will arrive. The life time of the Primary Prefix BC entry is determined by existence of references to HNP BC entries in the Primary Prefix BC entry. Once the last reference will disappear, LMA SHOULD start a timer for the Primary Prefix BC timeout. After the timer expiration the Primary Prefix BC entry MUST be deleted from LMA's binding cache. 6.2. Recieving Proxy Primary Prefix Request Upon receiving Proxy Primary Request Message LMA MUST allocate Primary prefix, which theoretically may be in the range 1 - 128 bits and insert a new BC entry corresponding to the allocated Primary prefix (see Section XXX). This entry MUST have a reference to the BC entry created earlier for the HNP contained in the Proxy Primary Prefix Request message. As a result of this operation LMA sends Proxy Primary Acknowledgement message with the result status code field set. This document defines two values of the status code: 0 - success, and 1 - failure. Later, the failure codes may be extended with additional values describing more precisely details of failure. 6.3. Prefix and BID Binding Registration Allocation of HNP prefixes to MN by LMA is performed according to the procedure described in [RFC5213]. The MN, which already received primary prefix may send BID registration at any time for some particular interface. For the purpose of backwards compatibility with [RFC5213], it is not mandatory for the SMA enabled MN to send BID registration for multiple interfaces configured in the MN. The only BID registration, which will be performed, is with regard to sending Primary Prefix Request message as described in Section XXX. By sending Primary Prefix message, mobile node indicates the fact that it wishes to start operation in simultaneous multi-access mode and creates at least one binding for a chosen interface. Upon receiving Proxy Primary Prefix BU message, LMA MUST create a Larsson, et al. Expires September 5, 2009 [Page 23] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 reference in the binding cache entry corresponding to the primary prefix and HNP sent in the Proxy Primary Prefix BU message. As the result of this operation, LMA MUST reply with the Proxy Primary Prefix BA message containing resulting status code in the Status field of the message. Status code values defined by this document described in Section XXX. 6.4. Sending Proxy Primary Prefix Update If LMA receives Proxy BU message, as specified in [RFC5213], indicating the fact that a mobile node moved to a different MAG, LMA MUST perform additional operations in the case the mobile node is SMA enabled and has previously configured Primary Prefix. o LMA MUST check in its BC if there is a Primary Prefix BC entry for the mobile node on behalf of which new MAG sent Proxy BU message. If yes, then o LMA MUST check if there is a reference to the HNP BC entry of the HNP, which is moved to the new MAG. If yes, then o LMA MUST send Proxy Primary Prefix Update message to the new MAG 6.5. Registration of Routing Rules Initial setup and consequent update of Routing Rules in LMA and MN is performed by Proxy Routing Rules Update message received by LMA if mobile node initiates operation, or sent by LMA if network initiates change of Routing rules. In both cases, the format of the Proxy Routing Rules Update message is identical. If LMA receives the Proxy Routing Rules Update it has to act in accordance with [I-D.eriksson-mext-mipv6-routing-rules] and associate new Routing Rules set with the Primary Prefix BC entry in LMA. All inbound traffic directed to Primary Prefix MUST be handled in accordance with the Routing Rules associated with the Primary Prefix BC entry in LMA. Larsson, et al. Expires September 5, 2009 [Page 24] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 7. New ICMP and Mobility Header messages A set of new ICMP messages are required for the communication between the mobile node and the MAG. Additionally, new Mobility Header messages are required as well as modifications to existing Mobility Header messages. 7.1. New ICMP Messages 7.1.1. ICMP Primary Prefix Request The ICMP Primary Prefix Request message is used by a mobile node to initiate allocation of a primary prefix. The mobile node sends the ICMP Primary Prefix Request message to the MAG. The source address of the packet is xxx and the destination address of the packet is the yyy address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | HNP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: ICMP Primary Prefix Request Message Type TBD by IANA Code 0 Checksum The ICMP checksum [RFC4443]. Sequence # A 16-bit unsigned integer used by the receiving node to sequence ICMP Primary Prefix Request messages and by the sending node to match a returned ICMP Primary Prefix Acknowledgement with this Larsson, et al. Expires September 5, 2009 [Page 25] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 ICMP Primary Prefix Request. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. HNP Length 8-bit unsigned integer indicating the length of the IPv6 Home Network Prefix. Home Network Prefix The home network prefix that will be bound to the new Primary Prefix allocated by the LMA. 7.1.2. ICMP Primary Prefix Acknowledgement The ICMP Primary Prefix Acknowledgement message is sent by the MAG to the mobile node to confirm the result of the allocation request. If the allocation was successful the status value is set to 0, otherwise an appropriate error code is set. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | PP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Primary Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: ICMP Primary Prefix Acknowledgement Type TBD by IANA Code TBD Larsson, et al. Expires September 5, 2009 [Page 26] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Checksum The ICMP checksum [RFC4443]. Sequence # The Sequence Number in the ICMP Primary Prefix Acknowledgement is copied from the Sequence Number field in the ICMP Primary Prefix Request. It is used by the mobile node in matching this ICMP Primary Prefix Acknowledgement with an outstanding ICMP Primary Prefix Request. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. PP Length 8-bit unsigned integer indicating the length of the IPv6 Primary Prefix. Primary Prefix The primary prefix that was allocated by the LMA to the mobile node. 7.1.3. ICMP Primary Prefix Binding Update The ICMP Primary Prefix Binding Update message is sent by the mobile node to the MAG to bind a home network prefix to a Binding Identifier (BID). Larsson, et al. Expires September 5, 2009 [Page 27] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Length | Sequence # | HNP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Identifier (BID) | Reserved | PP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Primary Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: ICMP Primary Prefix Binding Update Type TBD by IANA Code 0 Checksum The ICMP checksum [RFC4443]. Total Length The total length of the message in units of octets starting from and including the Type field. Sequence # A 16-bit unsigned integer used by the receiving node to sequence ICMP Primary Prefix Binding Update messages and by the sending node to match a returned ICMP Primary Prefix Binding Acknowledgement with this ICMP Primary Prefix Binding Update. Larsson, et al. Expires September 5, 2009 [Page 28] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 HNP Length 8-bit unsigned integer indicating the length of the IPv6 Home Network Prefix. Home Network Prefix The home network prefix that will be associated with the Binding Identifier listed in this message. Binding Identifier (BID) The Binding Identifier associated with the Home Network Prefix. This document preserves the established relation between a BID and CoA, as defined in [I-D.ietf-monami6-multiplecoa], but instead of using the CoA the Home Network Prefix is used. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. PP Length 8-bit unsigned integer indicating the length of the IPv6 Primary Prefix. Primary Prefix The primary prefix for which the BID - Home Network Prefix binding is valid. 7.1.4. ICMP Primary Prefix Binding Acknowledgement The ICMP Primary Prefix Binding Acknowledgement message is sent by the MAG to the mobile node to confirm the binding between the BID and the Home Network Prefix. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: ICMP Primary Prefix Binding Acknowledgement Type TBD by IANA Larsson, et al. Expires September 5, 2009 [Page 29] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Code TBD Checksum The ICMP checksum [RFC4443]. Sequence # The Sequence Number in the ICMP Primary Prefix Binding Acknowledgement is copied from the Sequence Number field in the ICMP Primary Prefix Binding Update. It is used by the mobile node in matching this ICMP Primary Prefix Binding Acknowledgement with an outstanding ICMP Primary Prefix Binding Update. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 7.1.5. ICMP Routing Rules Update This message is sent either by the mobile node or by the MAG to update the routing rules. The direction depends on whether the mobile node or the network is responsible for updating of the routing rules. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | PP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Primary Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Rules ... +-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: ICMP Routing Rules Update Larsson, et al. Expires September 5, 2009 [Page 30] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Type TBD by IANA Code TBD Checksum The ICMP checksum [RFC4443]. Sequence # The Sequence Number is either generated by the mobile node when the ICMP Routing Rule Update message is originated from the mobile node or copied from the Sequence Number field in the ICMP Routing Rules Update message to the ICMP Routing Rules Acknowledgement when received from the MAG. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. PP Length 8-bit unsigned integer indicating the length of the IPv6 Primary Prefix. Primary Prefix The primary prefix that was allocated by the LMA to the mobile node. Routing Rules A set of Routing Rules in ASCII text format according to [I-D.larsson-mext-flow-distribution-rules]. The set of routing rules is associated with the primary prefix. 7.1.6. ICMP Routing Rules Acknowledgement This message is sent either by the MAG or the mobile node to confirm the result of a previously sent ICMP Routing Rules Update. The direction depends on whether the mobile node or the network is responsible for updating of the routing rules. The result of the operation is indicated in the Code field. Larsson, et al. Expires September 5, 2009 [Page 31] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: ICMP Routing Rules Acknowledgement Type TBD by IANA Code TBD Checksum The ICMP checksum [RFC4443]. Sequence # If the ICMP Routing Rules Acknowledgement message is received from the MAG then the Sequence Number is used by the mobile node in matching this ICMP Routing Rules Acknowledgement with an outstanding ICMP Routing Rules Update. If the ICMP Routing Rules Acknowledgement message is sent from the mobile node then the Sequence Number in the ICMP Routing Rules Acknowledgement is copied from the Sequence Number field in the ICMP Routing Rules Update message. It is used by the receiving node in matching this ICMP Routing Rules Acknowledgement with an outstanding ICMP Routing Rules Update. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 7.2. New Mobility Header Messages A set of new Mobility Header messages are needed to map incoming ICMP messages to messages that can be transferred between the MAG and the LMA. The Mobility Header messages uses the format defined in [RFC3775]. 7.2.1. Proxy Primary Prefix Request Message If a mobile node decides to allocate a Primary Prefix (by sending an ICMP Primary Prefix Request), then the Proxy Primary Prefix Request message is sent by the MAG to the LMA requesting it to allocate a Primary Prefix for the mobile node. In doing so it forwards the Larsson, et al. Expires September 5, 2009 [Page 32] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 parameters in the received ICMP message and additionally adds the Mobile Node Identifier (MN-ID). The Proxy Primary Prefix Request message uses the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Binding Identifier (BID) | HNP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-ID Length | Subtype | MN-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: Proxy Primary Prefix Request Sequence # A 16-bit value specifying the sequence number of the message. The sequence number is a continuous number generated by the mobile node. It is copied from the Sequence Number field in the received ICMP Primary Prefix Request. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Binding Identifier (BID) Binding Identifier as specified in [I-D.ietf-monami6-multiplecoa]. HNP Length This field specifies the Home Network Prefix length. The value can be in the range of 1-128 according to [RFC5213]. Larsson, et al. Expires September 5, 2009 [Page 33] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Home Network Prefix The home network prefix that will be associated with the Binding Identifier parameter in this message. MN-ID Length A 8-bit value specifying the length of the MN-ID. Subtype A 8-bit value specifying type of MN-ID followed this field. The type of MN-ID is defined in [RFC4283]. MN-ID Variable length filed containing data according to the Subtype field in the message. 7.2.2. Proxy Primary Prefix Acknowledgement Message The Proxy Primary Prefix Acknowledgement is used to acknowledge receipt of a Proxy Primary Prefix Request. This message indicates success or failure of the operation in LMA and contains the Primary Prefix for the mobile node in case of success. The Proxy Primary Prefix Acknowledgement has the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | MN-ID Length | Subtype | PP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . MN-ID . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Primary Prefix . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: Proxy Primary Prefix Acknowledgement Larsson, et al. Expires September 5, 2009 [Page 34] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Sequence # A 16-bit value specifying Sequence Number of the message. The Sequence Number is is copied from the Sequence Number field in the Proxy Primary Prefix Request. It is used by the MAG in matching this Proxy Primary Prefix Acknowledgement with an outstanding Proxy Primary Prefix Request. Status A 16-bit value specifying the result of the Primary Prefix allocation in LMA. This document defines two values: 0 - Success 1 - Failure. MN-ID Length A 8-bit value specifying length of MN-ID. Subtype A 8-bit value specifying type of MN-ID followed this field. The type of MN-ID is defined in [RFC4283]. PP Length This field specifies the Home Network Prefix length. The value can be in the range of 1-128 according to [RFC5213]. MN-ID Variable length filed containing data according to the Subtype field in the message. Primary Prefix If the allocation was successful this field includes the Primary Prefix allocated by LMA for the mobile node. In case of an allocation failure this field is omitted. 7.2.3. Proxy Primary Prefix BU Message The Proxy Primary Prefix Binding Update requests a new binding between a BID and a Home Network Prefix in the mobile node. This message is sent from the MAG to the LMA when the MAG receives an ICMP Primary Prefix Binding Update from the mobile node. In doing so it forwards the parameters in the received ICMP message and additionally adds the Mobile Node Identifier (MN-ID). The Proxy Primary Prefix Binding Update message uses the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Larsson, et al. Expires September 5, 2009 [Page 35] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Identifier (BID) | MN-ID Length | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HNP Length | PP Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Primary Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . MN-ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: Proxy Primary Prefix Binding Update Sequence # A 16-bit value specifying the sequence number of the message. The sequence number is a continuous number generated by the mobile node. It is copied from the Sequence Number field in the received ICMP Primary Prefix Binding Update. Binding Identifier (BID) Binding Identifier as specified in [I-D.ietf-monami6-multiplecoa]. MN-ID Length A 8-bit value specifying the length of the MN-ID. Larsson, et al. Expires September 5, 2009 [Page 36] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Subtype A 8-bit value specifying type of MN-ID followed this field. The type of MN-ID is defined in [RFC4283]. HNP Length This field specifies the Home Network Prefix length. The value can be in the range of 1-128 according to [RFC5213]. PP Length This field specifies the Primary Prefix length. The value can be in the range of 1-128 according to [RFC5213].. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Home Network Prefix The Home Network Prefix associated with the Binding Identifier parameter in this message. Primary Prefix The Primary Prefix for which the binding between the BID and the Home Network Prefix is valid for. MN-ID Variable length filed containing data according to the Subtype field in the message. 7.2.4. Proxy Primary Prefix BA Message The Proxy Primary Prefix Binding Acknowledgement is used to acknowledge receipt of a Proxy Primary Prefix Binding Update. This message indicates whether the binding was successful or not. The Proxy Primary Prefix Binding Acknowledgement has the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Larsson, et al. Expires September 5, 2009 [Page 37] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | MN-ID Length | SubType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . MN-ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: Proxy Primary Prefix Binding Acknowledgement Sequence # A 16-bit value specifying the Sequence Number of the message. The Sequence Number is is copied from the Sequence Number field in the Proxy Primary Prefix Binding Update. It is used by the MAG in matching this Proxy Primary Prefix Binding Acknowledgement with an outstanding Proxy Primary Prefix Binding Update. Status A 16-bit value specifying the result of the binding request. This document defines two values: 0 - Success 1 - Failure. MN-ID Length A 8-bit value specifying length of MN-ID. Subtype A 8-bit value specifying type of MN-ID followed this field. The type of MN-ID is defined in [RFC4283]. MN-ID Variable length filed containing data according to the Subtype field in the message. 7.2.5. Proxy Primary Prefix Update Message Proxy Primary Prefix Update message is sent by LMA in the case when an attached interface in mobile node changes to a different MAG. The message is sent after new MAG and LMA accomplish Proxy Binding Update procedure according to [RFC5213]. The Proxy Primary Prefix Request message will trigger the new MAG to update its BUL accordingly. Larsson, et al. Expires September 5, 2009 [Page 38] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PP Length | MN ID Length | Subtype | MN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Primary Prefix . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number This is 16 bit value specifying sequence number of the message. The sequence number is the number generated by LMA. Primary Prefix Length This field specifies Primary Prefix length. The value can be in the range 1 -128. MN ID Length This is 8 bit value specifying length of MN's ID defined in [42...]. Subtype 8-bit integer specifying type of MN ID followed this field. The type of MN ID is defined in [RFC4283]. MN ID Variable length filed containing data according to the Subtype field in the message. Primary Prefix 128 bits filed containing Primary Prefix allocated previously by LMA to the MN. 7.2.6. Proxy Primary Prefix Update Ack Message Proxy Proxy Primary Prefix Update Ack Message is sent to LMA by MAG receiving Proxy Primary Prefix Update Message. The message is sent after MAG has accomplished all necessary updates of its BUL. Larsson, et al. Expires September 5, 2009 [Page 39] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | MN ID Length | Subtype | MN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number This is 16 bit value specifying sequence number of the message. The sequence number is copied from the correspondent Proxy Primary Prefix Update message. Status This is 8 bit value specifying result of the Primary Prefix Update operation in MAG. This document defines two values: 0 - success, and 1 - failure. Other codes giving more detailed information about failure type can be added in the future. MN ID Length This is 8 bit value specifying length of MN's ID defined in [42...]. Subtype 8-bit integer specifying type of MN ID followed this field. The type of MN ID is defined in [RFC4283]. MN ID Variable length filed containing data according to the Subtype field in the message. 7.2.7. Proxy Routing Rules Update Message The Proxy Routing Rules Update Message is sent either by the LMA or by the MAG, as a result of a received ICMP Routing Rules Update message. This message is bidirectional depending on whether the mobile node or the network is responsible for updating the routing rules.. The Proxy Routing Rules Update message uses the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Larsson, et al. Expires September 5, 2009 [Page 40] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Rules Length | MN-ID Length | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PP Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . MN-ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Primary Prefix . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Routing Rules . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure nn: Proxy Routing Rules Update Sequence # This is 16 bit value specifying sequence number of the message. The sequence number is the number copied from the correspondent Proxy Primary Prefix BU message. Routing Rules Length This field specifies Routing Rules [I-D.larsson-mext-flow-distribution-rules, I-D.eriksson-mext-mipv6-routing-rules] length. MN ID Length This is 8 bit value specifying length of MN's ID defined in [42...]. Subtype 8-bit integer specifying type of MN ID followed this field. The type of MN ID is defined in [42...]. MN ID Variable length filed containing data according to the Type field in the message. Larsson, et al. Expires September 5, 2009 [Page 41] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Primary Prefix Length This field specifies Primary Prefix [RFC5213] length and is similar to HNP Length. Primary Prefix 128 bits filed containing Primary Prefix allocated previously by LMA and delivered in the Proxy Primary Prefix Acknowledgement message. Roting Rules Routing Rules are transferred in the format specified in [I-D.larsson-mext-flow-distribution-rules, I-D.eriksson-mext-mipv6-routing-rules]. 7.2.8. Proxy Routing Rules Ack Message Proxy Routing Rules Ack Message is sent by LMA to inform involved nodes - MAG and MN about the result of operation of Routing Rules Update. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | MN ID Length | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . MN ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number This is 16 bit value specifying sequence number of the message. The sequence number is the number copied from the correspondent Proxy Primary Prefix BU message. Status This is 16 bit value specifying result of the Primary Prefix BU operation in LMA. This document defines two values: 0 - success, and 1 - failure. Other codes giving more detailed information about failure type can be added in the future. MN ID Length This is 8 bit value specifying length of MN's ID defined in [42...]. Larsson, et al. Expires September 5, 2009 [Page 42] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Subtype 8-bit integer specifying type of MN ID followed this field. The type of MN ID is defined in [42...]. MN ID Variable length filed containing data according to the Type field in the message. Larsson, et al. Expires September 5, 2009 [Page 43] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 8. Security Considerations TBD. Larsson, et al. Expires September 5, 2009 [Page 44] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 9. IANA Considerations This memo includes the following request to IANA. Larsson, et al. Expires September 5, 2009 [Page 45] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 10. Acknowledgements The authors would like to thank Yuri Ismailov for his contributions to this draft. Larsson, et al. Expires September 5, 2009 [Page 46] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 11.2. Informative References [I-D.eriksson-mext-mipv6-routing-rules] Eriksson, M., Larsson, C., and R. Kuntz, "Mobile IPv6 Flow Routing over Multiple Care-of Addresses", draft-eriksson-mext-mipv6-routing-rules-00 (work in progress), June 2008. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-11 (work in progress), January 2009. [I-D.larsson-mext-flow-distribution-rules] Larsson, C., Eriksson, M., Mitsuya, K., Tasaka, K., and R. Kuntz, "Flow Distribution Rule Language for Multi-Access Nodes", draft-larsson-mext-flow-distribution-rules-02 (work in progress), February 2009. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Larsson, et al. Expires September 5, 2009 [Page 47] Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009 Authors' Addresses Conny Larsson Ericsson Research Isafjordsgatan 14E Stockholm SE-164 80 Sweden Phone: +46 10 714 8458 Email: conny.larsson@ericsson.com Michael Eriksson Ericsson Research Isafjordsgatan 14E Stockholm SE-164 80 Sweden Phone: +46 10 717 5888 Email: michael.eriksson@ericsson.com Petter Arvidsson Ericsson Research Isafjordsgatan 14E Stockholm SE-164 80 Sweden Phone: +46 10 717 1803 Email: petter.p.arvidsson@ericsson.com Larsson, et al. Expires September 5, 2009 [Page 48]