< draft-berzin-malis-mpls-mobility-00.txt		draft-berzin-malis-mpls-mobility-01.txt >
	Network Working Group O. Berzin		Network Working Group O. Berzin
	Internet-Draft A. Malis		Internet-Draft A. Malis
	Expires: May 2, 2008 Verizon Communications		Expires: October 30, 2008 Verizon Communications
	October 30, 2007		April 28, 2008
	Mobility Support Using MPLS and MP-BGP Signaling		Mobility Support Using MPLS and MP-BGP Signaling
	draft-berzin-malis-mpls-mobility-00.txt		draft-berzin-malis-mpls-mobility-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 2, 2008.		This Internet-Draft will expire on October 30, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document describes a new approach to handling user mobility at		This document describes a new approach to handling user mobility at
	the network layer in the context of Multiprotocol Label Switched		the network layer in the context of Multi-Protocol Label Switched
	Networks (MPLS). This approach does not rely on the existing IP		Networks (MPLS). This approach does not rely on the existing IP
	mobility management protocols such as Mobile IP, and is instead based		mobility management protocols such as Mobile IP, and is instead based
	on the combination of Multiprotocol BGP (MP-BGP) and MPLS. This		on the combination of Multi-Protocol BGP (MP-BGP) and MPLS. This
	document proposes to introduce new protocol elements to MP-BGP to		document proposes to introduce new protocol elements to MP-BGP to
	achieve Mobility Label distribution at the network control plane and		achieve Mobility Label distribution at the network control plane and
	the optimal packet delivery to the mobile node by the network		the optimal packet delivery to the mobile node by the network
	forwarding plane using MPLS.		forwarding plane using MPLS.
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Architecture Requirements . . . . . . . . . . . . . . . . 6		2.1. Architecture Requirements . . . . . . . . . . . . . . . . 6
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	3.1.3.1. Mobile Host Registration - IPv4 . . . . . . . . . 22		3.1.3.1. Mobile Host Registration - IPv4 . . . . . . . . . 22
	3.1.3.1.1. Lightweight Registration - IPv4 . . . . . . . 22		3.1.3.1.1. Lightweight Registration - IPv4 . . . . . . . 22
	3.1.3.1.2. Full Registration - IPv4 . . . . . . . . . . . 23		3.1.3.1.2. Full Registration - IPv4 . . . . . . . . . . . 23
	3.1.3.1.3. Group Registration - IPv4 . . . . . . . . . . 25		3.1.3.1.3. Group Registration - IPv4 . . . . . . . . . . 25
	3.1.3.2. Mobile Router Registration - IPv4 . . . . . . . . 29		3.1.3.2. Mobile Router Registration - IPv4 . . . . . . . . 29
	3.1.3.2.1. Routing Adjacency Establishment . . . . . . . 29		3.1.3.2.1. Routing Adjacency Establishment . . . . . . . 29
	3.1.4. Registration and Status - IPv6 . . . . . . . . . . . . 30		3.1.4. Registration and Status - IPv6 . . . . . . . . . . . . 30
	3.2. Integration with MP-BGP . . . . . . . . . . . . . . . . . 30		3.2. Integration with MP-BGP . . . . . . . . . . . . . . . . . 30
	3.2.1. Mobility Address Family . . . . . . . . . . . . . . . 30		3.2.1. Mobility Address Family . . . . . . . . . . . . . . . 30
	3.2.2. Mobility Bindings . . . . . . . . . . . . . . . . . . 32		3.2.2. Mobility Bindings . . . . . . . . . . . . . . . . . . 32
	3.2.3. Group Registration Management with MP-BGP . . . . . . 34		3.2.3. Group Registration Management with MP-BGP . . . . . . 35
	3.2.4. BGP Capability Advertisement . . . . . . . . . . . . . 37		3.2.4. BGP Capability Advertisement . . . . . . . . . . . . . 37
	3.3. Mobile Application Priority Indication and Recognition . . 37		3.3. Mobile Application Priority Indication and Recognition . . 38
	3.4. Application Service Type Indication . . . . . . . . . . . 38		3.4. Application Service Type Indication . . . . . . . . . . . 38
	4. Network Update and Hand-off Processing . . . . . . . . . . . . 39		4. Network Update and Hand-off Processing . . . . . . . . . . . . 40
	4.1. Network Update Modes . . . . . . . . . . . . . . . . . . . 39		4.1. Network Update Modes and Types . . . . . . . . . . . . . . 40
	4.1.1. Unsolicited Downstream Push . . . . . . . . . . . . . 39		4.1.1. Unsolicited Downstream Push Mode . . . . . . . . . . . 40
	4.1.2. Selective Downstream Push . . . . . . . . . . . . . . 39		4.1.2. Selective Downstream Push Mode . . . . . . . . . . . . 40
	4.1.3. Predictive Downstream Push . . . . . . . . . . . . . . 39		4.1.3. Predictive Downstream Push Mode . . . . . . . . . . . 40
	4.1.4. Hierarchical On-Demand Distribution . . . . . . . . . 40		4.1.4. Hierarchical On-Demand Distribution Mode . . . . . . . 41
	4.1.4.1. On-Demand Requests for Mobility Binding		4.1.4.1. On-Demand Requests for Mobility Binding
	Information . . . . . . . . . . . . . . . . . . . 40		Information . . . . . . . . . . . . . . . . . . . 41
	4.1.5. Network Hierarchy Considerations . . . . . . . . . . . 43		4.1.5. Network Update Types . . . . . . . . . . . . . . . . . 44
	4.1.6. Regionalization and Scalability . . . . . . . . . . . 43		4.1.5.1. Internal Update Type . . . . . . . . . . . . . . . 44
	4.1.6.1. Mobility Information Location System (MILS) . . . 44		4.1.5.2. External Update Type . . . . . . . . . . . . . . . 44
	4.2. Hand-off Processing . . . . . . . . . . . . . . . . . . . 46		4.1.6. Network Hierarchy Considerations . . . . . . . . . . . 44
	4.3. Micro-Mobility Handling . . . . . . . . . . . . . . . . . 47		4.1.7. Regionalization and Scalability . . . . . . . . . . . 45
	4.3.1. Local Micro-Mobility . . . . . . . . . . . . . . . . . 47		4.1.7.1. Hierarchical Mobility Label Based Network
	4.3.2. Group Micro-Mobility . . . . . . . . . . . . . . . . . 47		(H-MLBN) . . . . . . . . . . . . . . . . . . . . . 46
	5. Datagram Delivery . . . . . . . . . . . . . . . . . . . . . . 49		4.2. Hand-off Processing . . . . . . . . . . . . . . . . . . . 47
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 50		4.3. Micro-Mobility Handling . . . . . . . . . . . . . . . . . 48
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51		4.3.1. Local Micro-Mobility . . . . . . . . . . . . . . . . . 49
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52		4.3.2. Group Micro-Mobility . . . . . . . . . . . . . . . . . 49
	9. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 53		5. Datagram Delivery . . . . . . . . . . . . . . . . . . . . . . 50
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54		6. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 54		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
	10.2. Informative References . . . . . . . . . . . . . . . . . . 54		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56		9. Patent Issues . . . . . . . . . . . . . . . . . . . . . . . . 54
	Intellectual Property and Copyright Statements . . . . . . . . . . 57		10. Changes from Previous Revisions . . . . . . . . . . . . . . . 55
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
			11.1. Normative References . . . . . . . . . . . . . . . . . . . 56
			11.2. Informative References . . . . . . . . . . . . . . . . . . 56
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
			Intellectual Property and Copyright Statements . . . . . . . . . . 59
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	The requirements to support user mobility range from the physical		The requirements to support user mobility range from the physical
	aspects of wireless access networks to the logical aspects of the		aspects of wireless access networks to the logical aspects of the
	network control and forwarding plane operation. In the context of		network control and forwarding plane operation. In the context of
	this work the main requirement for the mobility support architecture		this work the main requirement for the mobility support architecture
	is to decouple the network layer addressing and the associated		is to de-couple the network layer addressing and the associated
	logical network topology from the ability of the network to optimally		logical network topology from the ability of the network to optimally
	deliver the packets to the mobile user. The optimal traffic delivery		deliver the packets to the mobile user. The optimal traffic delivery
	is interpreted as the delivery of packets to the new node location		is interpreted as the delivery of packets to the new node location
	following the best (often the shortest in terms of the routing		following the best (often the shortest in terms of the routing
	protocol metrics) path between the mobile node and the correspondent		protocol metrics) path between the mobile node and the correspondent
	node.		node.
	The issue is that this optimal path cannot be used by the network to		The issue is that this optimal path cannot be used by the network to
	communicate with the mobile user based on the IP address and routing		communicate with the mobile user based on the IP address and routing
	protocols. This is due to the inability of a conventional IP network		protocols. This is due to the inability of a conventional IP network
	skipping to change at page 5, line 51 ¶		skipping to change at page 5, line 51 ¶
	This document proposes to use the Mobility Label as a second label in		This document proposes to use the Mobility Label as a second label in
	the MPLS label stack. The first label in the stack is the one that		the MPLS label stack. The first label in the stack is the one that
	identifies the LSP (Label Switched Path) between the two Label Edge		identifies the LSP (Label Switched Path) between the two Label Edge
	Routers and the second label in the stack can be used to identify the		Routers and the second label in the stack can be used to identify the
	IP address of the mobile node and deliver the traffic to it. The		IP address of the mobile node and deliver the traffic to it. The
	assignment and the distribution of the first label in the stack is		assignment and the distribution of the first label in the stack is
	handled by the conventional MPLS architecture elements and protocols		handled by the conventional MPLS architecture elements and protocols
	such as LDP (Label Distribution Protocol [RFC5036]). It is proposed		such as LDP (Label Distribution Protocol [RFC5036]). It is proposed
	that the assignment and distribution of the second label - the		that the assignment and distribution of the second label - the
	Mobility Label - be based on the existing framework of MP-BGP		Mobility Label - be based on the existing framework of MP-BGP (Multi-
	(Multiprotocol Border Gateway Protocol [RFC4760]). The mobility		Protocol Border Gateway Protocol [RFC4760]). The mobility management
	management scheme based on MP-BGP at the control plane level and MPLS		scheme based on MP-BGP at the control plane level and MPLS at the
	at the forwarding plane level represents a system in which both the		forwarding plane level represents a system in which both the control
	control and forwarding processes are integrated to ensure the optimal		and forwarding processes are integrated to ensure the optimal traffic
	traffic delivery that is not fully achieved in the existing network		delivery that is not fully achieved in the existing network layer
	layer mobility management approaches.		mobility management approaches.
	2.1. Architecture Requirements		2.1. Architecture Requirements
	Integrated control and forwarding plane - the network update process		Integrated Control and Forwarding Plane - the network update process
	by the Control Plane must result in the optimal traffic delivery by		by the Control Plane must result in the optimal traffic delivery by
	the Forwarding Plane.		the Forwarding Plane.
	Robust and flexible protocol framework - the Mobility Management		Robust and Flexible Protocol Framework - Mobility Management Control
	Control Plane Protocol and the associated functions must be placed at		Plane Protocol and the associated functions must be placed at the
	the intelligent network edges and allow to avoid the need to involve		intelligent network edges and allow to avoid the need to involve all
	all nodes in the network (including the core nodes) in the network		nodes in the network (including the core nodes) in the network update
	update process.		process.
	The Mobility Management Control Plane Protocol must allow for		Mobility Management Control Plane Protocol must allow for flexible
	flexible and seamless introduction of new features and for support		and seamless introduction of new features and for support for Mobile
	for Mobile Hosts and Mobile Routers.		Hosts and Mobile Routers.
	Evolutionary architecture and implementation approach - the Mobility		Evolutionary Architecture and Implementation Approach - Mobility
	Management scheme should be based as much as possible on the existing		Management scheme should be based as much as possible on the existing
	network architectures and protocol framework. Only minimal changes		network architectures and protocol framework. Only minimal changes
	to the operation of mobile nodes should be expected.		to the operation of mobile nodes should be expected.
	Efficient network responsiveness - the impact on the mobile		Efficient Network Responsiveness - the impact on the mobile
	application due to the service disruption caused by the mobile node's		application due to the service disruption caused by the mobile node's
	movements and the associated network update and delivery processes		movements and the associated network update and delivery processes
	should be reasonably minimal.		should be reasonably minimal.
	Acceptable network scalability and performance - the new requirements		Acceptable Network Scalability and Performance - the new requirements
	for Mobility Management functions should not result in decreased		for Mobility Management functions should not result in decreased
	network scalability and performance.		network scalability and performance.
	2.2. Existing Solutions		2.2. Existing Solutions
	2.2.1. Mobile IP		2.2.1. Mobile IP
	Mobile IP [RFC3344] was developed to provide macro mobility		Mobile IP [RFC3344] was developed to provide macro mobility
	management for the mobile hosts using IP version 4 (IPv4). It was		management for the mobile hosts using IP version 4 (IPv4). It was
	subsequently extended to support IPv6. Due to its complete reliance		subsequently extended to support IPv6. Due to its complete reliance
	on the logical network topology determined by the distribution of the		on the logical network topology determined by the distribution of the
	IP subnets Mobile IP solves the mobility problem by using the		IP sub-nets Mobile IP solves the mobility problem by using the
	following two major techniques: mobile node registration and traffic		following two major techniques: mobile node registration and traffic
	tunneling. The main entities in Mobile IP are the Mobile Node (MN)		tunneling. The main entities in Mobile IP are the Mobile Node (MN)
	itself, the Correspondent Node (CN) - the host that is communicating		itself, the Correspondent Node (CN) - the host that is communicating
	with the MN, the Home Agent (HA) - this is the router that owns the		with the MN, the Home Agent (HA) - this is the router that owns the
	original home subnet to which the MN is assigned, the Foreign Agent		original home sub-net to which the MN is assigned, the Foreign Agent
	(FA) - this is the router that owns the subnet to which the MN has		(FA) - this is the router that owns the sub-net to which the MN has
	moved (the foreign subnet), and finally the Care-of-Address (CoA) -		moved (the foreign sub-net), and finally the Care-of-Address (CoA) -
	the IP address that belongs to the FA and that is used to represent		the IP address that belongs to the FA and that is used to represent
	the MN while it is located in the foreign subnet. The basic mobility		the MN while it is located in the foreign sub-net. The basic
	handling by Mobile IP results in a sub-optimal forwarding path in the		mobility handling by Mobile IP results in a sub-optimal forwarding
	direction of traffic from the CN to the new location of the MN. This		path in the direction of traffic from the CN to the new location of
	is because the traffic is first sent to the HA and then tunneled to		the MN. This is because the traffic is first sent to the HA and then
	the FA/MN. Although the route optimization scheme exists where the		tunneled to the FA/MN. Although the route optimization scheme exists
	mobility bindings are sent by the HA directly to the CN with the CoA		where the mobility bindings are sent by the HA directly to the CN
	of the MN for direct traffic forwarding, it requires the CN to i)		with the CoA of the MN for direct traffic forwarding, it requires the
	implement the binding processing and ii) use IP tunneling to send		CN to i) implement the binding processing and ii) use IP tunneling to
	packets to the MN.		send packets to the MN.
	2.2.2. Mobile IPv6/HMIP/NEMO		2.2.2. Mobile IPv6/HMIP/NEMO
	Mobile IPv6 [RFC3775] provides macro-mobility support for IPv6. It		Mobile IPv6 [RFC3775] provides macro-mobility support for IPv6. It
	improves Mobile IPv4 by eliminating the need for the FA, use of the		improves Mobile IPv4 by eliminating the need for the FA, use of the
	IPv6 neighbor discovery instead of ARP, use of the IPv6 Link Local		IPv6 neighbor discovery instead of ARP, use of the IPv6 Link Local
	(LLOC) address instead of CoA. It also provides basic support for		(LLOC) address instead of CoA. It also provides basic support for
	mobile routers via NEMO (Network Mobility) [RFC3963] and enables		mobile routers via NEMO (Network Mobility) [RFC3963] and enables
	hierarchical mobility management (HMIP). However MIPv6 does not		hierarchical mobility management (HMIP). However MIPv6 does not
	provide for the integration of the control and forwarding planes and		provide for the integration of the control and forwarding planes and
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 22 ¶
	2.3. Protocol Overview		2.3. Protocol Overview
	MP-BGP and its ability to carry the overlay MPLS label information		MP-BGP and its ability to carry the overlay MPLS label information
	[RFC3107] is proposed for the mobility management. Namely when the		[RFC3107] is proposed for the mobility management. Namely when the
	mobile hosts or routers change their network locations they can		mobile hosts or routers change their network locations they can
	register with the edge nodes of the MPLS network (LER) and at that		register with the edge nodes of the MPLS network (LER) and at that
	time assigned Mobility Labels. The Mobility Labels in turn are		time assigned Mobility Labels. The Mobility Labels in turn are
	associated with the IP addresses of mobile hosts or routers thus		associated with the IP addresses of mobile hosts or routers thus
	forming the Mobility Bindings. These Mobility Bindings are then		forming the Mobility Bindings. These Mobility Bindings are then
	encoded in the Multiprotocol BGP Address Family messaging structure		encoded in the Multi-Protocol BGP Address Family messaging structure
	and are distributed among the rest of the MPLS network LER nodes		and are distributed among the rest of the MPLS network LER nodes
	using the MP-BGP protocol. The Mobility Binding provides an explicit		using the MP-BGP protocol. The Mobility Binding provides an explicit
	association between the overlay MPLS label and a single or multiple		association between the overlay MPLS label and a single or multiple
	individual IP addresses of mobile hosts or IP address ranges		individual IP addresses of mobile hosts or IP address ranges
	(prefixes) that are served by mobile routers. The MP-BGP NEXT_HOP		(prefixes) that are served by mobile routers. The MP-BGP NEXT_HOP
	attribute associated with the BGP UPDATE message [RFC4271] used to		attribute associated with the BGP UPDATE message [RFC4271] used to
	carry the Mobility Binding provides an implicit association between		carry the Mobility Binding provides an implicit association between
	the overlay Mobility Label and the infrastructure MPLS label that is		the overlay Mobility Label and the infrastructure MPLS label that is
	in turn associated with the LSP to reach the LER that sourced the		in turn associated with the LSP to reach the LER that sourced the
	Mobility Binding. The MPLS LER capability to provide mobility		Mobility Binding. The MPLS LER capability to provide mobility
	support can be referred to as the Mobility Support Function (MSF)		support can be referred to as the Mobility Support Function (MSF)
	(see Section 3). The MSF includes: a) Mobile Host/Router Discovery,		(see Section 3). The MSF includes: a) Mobile Host/Router Discovery,
	Registration and Status Procedures, b) Mobility Label Association and		Registration and Status Procedures, b) Mobility Label Association and
	de-Association Procedures, c) Integration with MP- BGP and d) Mobile		de-Association Procedures, c) Integration with MP- BGP and d) Mobile
	Application Priority Indication and Recognition.		Application Priority Indication and Recognition. Please see [MLBN].
	2.4. Architecture Overview		2.4. Architecture Overview
	This mobility architecture is proposed in the context of MPLS		This mobility architecture is proposed in the context of MPLS
	networks. As such it is a requirement of this architecture that all		networks. As such it is a requirement of this architecture that all
	nodes in the network support MPLS control and forwarding plane		nodes in the network support MPLS control and forwarding plane
	procedures and in particular it is a further requirement that the		procedures and in particular it is a further requirement that the
	edge nodes of the MPLS network implement the Mobility Support		edge nodes of the MPLS network implement the Mobility Support
	Function described in Section 3. This architecture does not rely on		Function described in Section 3. This architecture does not rely on
	Mobile IP for macro-mobility support. In other words there is no		Mobile IP for macro-mobility support. In other words there is no
	skipping to change at page 9, line 13 ¶		skipping to change at page 9, line 13 ¶
	router is always identified as being in the foreign network thus		router is always identified as being in the foreign network thus
	always requiring mobility support. In addition, there is no		always requiring mobility support. In addition, there is no
	requirement for the CoA.		requirement for the CoA.
	The simplest way to implement this assumption is to administratively		The simplest way to implement this assumption is to administratively
	allocate a range of IP addresses for all mobile hosts and routers of		allocate a range of IP addresses for all mobile hosts and routers of
	an organization and to implement in the MSF the configurable ability		an organization and to implement in the MSF the configurable ability
	to recognize the pre-allocated mobility address ranges. As such, a		to recognize the pre-allocated mobility address ranges. As such, a
	service provider would assign IP addresses to all of their mobile		service provider would assign IP addresses to all of their mobile
	subscribers from a pre-allocated address range. This range does not		subscribers from a pre-allocated address range. This range does not
	have to be flat and can be in turn subnetted. The IPv4 or IPv6		have to be flat and can be in turn sub-netted. The IPv4 or IPv6
	mobility address pre-allocation scheme allows utilization of this		mobility address pre-allocation scheme allows utilization of this
	mobility management architecture as a separate overlay MPLS service.		mobility management architecture as a separate overlay MPLS service.
	The only requirement related to the LER MSF pre-configuration is the		The only requirement related to the LER MSF pre-configuration is the
	static identification of the overall mobility address range in the		static identification of the overall mobility address range in the
	scope of the LER-wide MSF.		scope of the LER-wide MSF.
	Regardless of the static identification of the overall address range		Regardless of the static identification of the overall address range
	allocated to the mobile devices, the individual mobile nodes identify		allocated to the mobile devices, the individual mobile nodes identify
	themselves dynamically to the MSF. This capability is especially		themselves dynamically to the MSF. This capability is especially
	useful when this architecture is applied to provide mobility support		useful when this architecture is applied to provide mobility support
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 20 ¶
	2.4.2. Attachment Options		2.4.2. Attachment Options
	The two major access interface options considered here are: Direct		The two major access interface options considered here are: Direct
	Attachment of the LER node to the Radio Access Network and Indirect		Attachment of the LER node to the Radio Access Network and Indirect
	Attachment of the LER node to the Radio Access Network. The terms		Attachment of the LER node to the Radio Access Network. The terms
	direct and indirect are not used to indicate that the LER node has or		direct and indirect are not used to indicate that the LER node has or
	does not have the integrated wireless radio interface. The term		does not have the integrated wireless radio interface. The term
	direct is used to reflect that a direct layer 2 path exists between		direct is used to reflect that a direct layer 2 path exists between
	the mobile node and the MSF enabled LER either via the integrated		the mobile node and the MSF enabled LER either via the integrated
	radio interface or via the wireline grooming network to the wireline		radio interface or via the wire-line grooming network to the wire-
	side of the Radio Access Network Base Stations. The term Indirect is		line side of the Radio Access Network Base Stations. The term
	used to reflect that there is no direct layer 2 path between the		Indirect is used to reflect that there is no direct layer 2 path
	Radio Access Network and the MSF enabled LER node. The Indirect		between the Radio Access Network and the MSF enabled LER node. The
	Attachment means that there is another layer 3 device (such as the		Indirect Attachment means that there is another layer 3 device (such
	Customer Edge - CE router in the MPLS Architecture terminology)		as the Customer Edge - CE router in the MPLS Architecture
	between the MSF enabled LER and the Radio Access Network. The CE		terminology) between the MSF enabled LER and the Radio Access
	router in turn connects to the Radio Network via Direct Attachment		Network. The CE router in turn connects to the Radio Network via
	(in the sense of the term defined here) by using the integrated		Direct Attachment (in the sense of the term defined here) by using
	wireless interface or by using the wireline grooming network. The		the integrated wireless interface or by using the wire-line grooming
	reason for establishing these two access options relates to the type		network. The reason for establishing these two access options
	of service environments that the proposed architecture will most		relates to the type of service environments that the proposed
	likely be applicable to.		architecture will most likely be applicable to.
	The Direct Attachment option is most suitable for the use case where		The Direct Attachment option is most suitable for the use case where
	mobility is offered as an overlay service in a service provider's		mobility is offered as an overlay service in a service provider's
	mobility enabled MPLS network. In this case the Mobility Support		mobility enabled MPLS network. In this case the Mobility Support
	Function may be viewed as one of the functions in the MPLS for Mobile		Function may be viewed as one of the functions in the MPLS for Mobile
	Networks Architecture. An example of such a use case is the Wireless		Networks Architecture. An example of such a use case is the Wireless
	Telephone service with data or multimedia capabilities (such as		Telephone service with data or multi-media capabilities (such as
	EV-DO) in which mobility management is handled by the MSF enabled		EV-DO) in which mobility management is handled by the MSF enabled
	MPLS network. The mobile nodes may be the wireless telephone sets		MPLS network. The mobile nodes may be the wireless telephone sets
	with IPv4 or IPv6 stacks and the corresponding mobility addresses		with IPv4 or IPv6 stacks and the corresponding mobility addresses
	assigned by the service provider, communicating via the Radio Access		assigned by the service provider, communicating via the Radio Access
	Network Base Stations to the MSF enabled LER nodes. A simple		Network Base Stations to the MSF enabled LER nodes. A simple
	registration procedure triggers the assignment of the overlay		registration procedure triggers the assignment of the overlay
	Mobility Labels and the subsequent mobility management by MP-BGP.		Mobility Labels and the subsequent mobility management by MP-BGP.
	The Indirect Attachment option is most suitable when the mobility		The Indirect Attachment option is most suitable when the mobility
	service is integrated with other overlay MPLS services such as Layer		service is integrated with other overlay MPLS services such as Layer
	skipping to change at page 11, line 24 ¶		skipping to change at page 11, line 24 ¶
	therefore no need to integrate the CE routers with the service		therefore no need to integrate the CE routers with the service
	provider's MPLS infrastructure. The MPLS LER (PE) router will need		provider's MPLS infrastructure. The MPLS LER (PE) router will need
	to accept the Mobility Binding information via the use of MP-BGP from		to accept the Mobility Binding information via the use of MP-BGP from
	the CE router within the MPLS VPN and then propagate that information		the CE router within the MPLS VPN and then propagate that information
	into the MPLS network using the L3 VPN MPLS overlay service also		into the MPLS network using the L3 VPN MPLS overlay service also
	based on MP-BGP.		based on MP-BGP.
	The direct attachment option is shown in Fig.1, where a MSF enabled		The direct attachment option is shown in Fig.1, where a MSF enabled
	LER node interfaces with multiple Radio Cells or Cell Clusters via		LER node interfaces with multiple Radio Cells or Cell Clusters via
	the L2 network such as Ethernet. Each Radio Cell Cluster is assigned		the L2 network such as Ethernet. Each Radio Cell Cluster is assigned
	into a L2 Virtual LAN and associated with a L3 subnet that is		into a L2 Virtual LAN and associated with a L3 sub-net that is
	terminated at a logical interface of the LER node. The logical		terminated at a logical interface of the LER node. The logical
	interfaces are controlled by the MSF and the associated set of Radio		interfaces are controlled by the MSF and the associated set of Radio
	Cells or Clusters forms a Mobility Region.		Cells or Clusters forms a Mobility Region.
	In Fig. 2 a similar arrangement is illustrated but in this case there		In Fig. 2 a similar arrangement is illustrated but in this case there
	is no direct L2 path between the Radio Access Network and the MPLS		is no direct L2 path between the Radio Access Network and the MPLS
	edge. A CE router provides the MSF and communicates the Mobility		edge. A CE router provides the MSF and communicates the Mobility
	Binding information by means of MP-BGP to the MPLS LER (PE) router.		Binding information by means of MP-BGP to the MPLS LER (PE) router.
	+-----+		+-----+
	skipping to change at page 13, line 30 ¶		skipping to change at page 13, line 30 ¶
	\ / \ ``-.-+'((++)) \		\ / \ ``-.-+'((++)) \
	`-----' `. .----`-. || )		`-----' `. .----`-. || )
	Base Station \ / \\`-.+ /		Base Station \ / \\`-.+ /
	`. ((++)) \\ /		`. ((++)) \\ /
	( \ || `)----'		( \ || `)----'
	\ `.++ /		\ `.++ /
	\ /		\ /
	`-----'		`-----'
	Base Station		Base Station
	Indirect Attachment Option		In-Direct Attachment Option
	Figure 2		Figure 2
	2.4.3. Network Hierarchy		2.4.3. Network Hierarchy
	The distribution of the Mobility Binding information using MP-BGP may		The distribution of the Mobility Binding information using MP-BGP may
	be achieved by constructing a flat or hierarchical MP-BGP peering		be achieved by constructing a flat or hierarchical MP-BGP peering
	topology among the participating LER nodes. The flat peering logical		topology among the participating LER nodes. The flat peering logical
	structure requires a full mesh of MP-BGP sessions and the		structure requires a full mesh of MP-BGP sessions and the
	hierarchical peering structure can make use of the BGP Route		hierarchical peering structure can make use of the BGP Route
	skipping to change at page 15, line 34 ¶		skipping to change at page 15, line 34 ¶
	with the MLBN Extension is referred to as the MSF Discovery message.		with the MLBN Extension is referred to as the MSF Discovery message.
	The MSF Discovery message should carry the information about the type		The MSF Discovery message should carry the information about the type
	of the mobile node: Mobile Host or Mobile Router.		of the mobile node: Mobile Host or Mobile Router.
	Upon receipt of the MSF Discovery message the MSF LER must respond		Upon receipt of the MSF Discovery message the MSF LER must respond
	with the ICMP Router Advertisement including the MLBN specific		with the ICMP Router Advertisement including the MLBN specific
	Extension. This message is referred to as the MSF Advertisement.		Extension. This message is referred to as the MSF Advertisement.
	The MSF Advertisement will carry different information depending on		The MSF Advertisement will carry different information depending on
	the type of the mobile node and the registration mode.		the type of the mobile node and the registration mode.
	0 1 2 3		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		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 |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF Discovery Extension TLV (variable) |		| MSF Discovery Extension TLV (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ICMP Router Solicitation with MSF Discovery Extension		ICMP Router Solicitation with MSF Discovery Extension
	Figure 3		Figure 3
	Link Layer Fields: Destination Address - This should be the		Link Layer Fields: Destination Address - This should be the
	multicast or broadcast Link Layer Address.		multicast or broadcast Link Layer Address.
	IP Fields: Source Address - IP Address of the Mobile Host or IP		IP Fields: Source Address - IP Address of the Mobile Host or IP
	address of the interface of the Mobile Router from which this		address of the interface of the Mobile Router from which this
	skipping to change at page 16, line 21 ¶		skipping to change at page 16, line 21 ¶
	Destination Address - This is the all-routers multicast address		Destination Address - This is the all-routers multicast address
	224.0.0.2 or the limited broadcast address 255.255.255.255.		224.0.0.2 or the limited broadcast address 255.255.255.255.
	TTL - TTL should be set to 1.		TTL - TTL should be set to 1.
	ICMP Fields: Type = 10 Router Solicitation.		ICMP Fields: Type = 10 Router Solicitation.
	Code = 1 MLBN MSF Discovery Extension included.		Code = 1 MLBN MSF Discovery Extension included.
	0 1 2 3		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		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 |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Num Addrs |Addr Entry Size| Lifetime |		| Num Addrs |Addr Entry Size| Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router Address |		| Router Address[1] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preference Level |		| Preference Level[1] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF Advertisement Extension (variable) |		| MSF Advertisement Extension (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ICMP Router Advertisement with MSF Advertisement Extension		ICMP Router Advertisement with MSF Advertisement Extension
	Figure 4		Figure 4
	Link Layer Fields: Destination Address - This should be the source		Link Layer Fields: Destination Address - This should be the source
	address used to deliver the MSF Discovery message from the mobile		address used to deliver the MSF Discovery message from the mobile
	node.		node.
	IP Fields: Source Address - IP Address of the MSF.		IP Fields: Source Address - IP Address of the MSF.
	skipping to change at page 17, line 18 ¶		skipping to change at page 17, line 18 ¶
	Please refer to [RFC1256] for the specification of the remaining		Please refer to [RFC1256] for the specification of the remaining
	fields in both of the above messages.		fields in both of the above messages.
	3.1.1.1. MSF Discovery by Mobile Hosts - IPv4		3.1.1.1. MSF Discovery by Mobile Hosts - IPv4
	Mobile hosts should initiate the MSF Discovery process by sending the		Mobile hosts should initiate the MSF Discovery process by sending the
	MSF Discovery message. The MSF Discovery Extension format for Mobile		MSF Discovery message. The MSF Discovery Extension format for Mobile
	Hosts is shown below.		Hosts is shown below.
	0 1 2 3		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		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 | Length |H|Pri. |L|ASTI | Region_ID |		| Type | Length |H|Pri. |L|ASTI | Area_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobile Host IPv4 Source Address |		| Mobile Host IPv4 Source Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Correlation ID |		| Correlation ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Mobile Host MSF Discovery Extension for IPv4		Mobile Host MSF Discovery Extension for IPv4
	Figure 5		Figure 5
	Type - 0 = MSF Discovery		Type - 0 = MSF Discovery
	Length - Length of the message in octets.		Length - Length of the message in octets.
	H - Mobile Node Type Indication. 0 = Mobile Host.		H - Mobile Node Type Indication. 0 = Mobile Host.
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 5 ¶
	L - Lightweight Registration Requested (1).		L - Lightweight Registration Requested (1).
	ASTI - Application Service Type Indication. This 3-bit field may		ASTI - Application Service Type Indication. This 3-bit field may
	be used to indicate to the MSF what type of service is to be used		be used to indicate to the MSF what type of service is to be used
	by the mobile host. For example, "Internet Access Only" or Full		by the mobile host. For example, "Internet Access Only" or Full
	Mobile-to-Mobile Routing". This indication can then be mapped to		Mobile-to-Mobile Routing". This indication can then be mapped to
	the Network Update Mode Code used in the Mobility Binding		the Network Update Mode Code used in the Mobility Binding
	structure.		structure.
	Region_ID - An Identifier (1-255) associated with the Regional		Area_ID - An Identifier (1-255) associated with the Area Mobility
	Mobility Route Reflector. Region_ID=0 must be used for initial		Route Reflector. Area_ID=0 must be used for initial registrations
	registrations by mobile nodes.		by mobile nodes.
	Correlation ID - a number used to keep track of the Lightweight		Correlation ID - a number used to keep track of the Lightweight
	Registration message pairs - MSF Discovery/MSF Advertisement.		Registration message pairs - MSF Discovery/MSF Advertisement.
	3.1.1.2. MSF Discovery by Mobile Routers - IPv4		3.1.1.2. MSF Discovery by Mobile Routers - IPv4
	Mobile routers should initiate the MSF Discovery process by sending		Mobile routers should initiate the MSF Discovery process by sending
	the MSF Discovery message. The MSF Discovery Extension format for		the MSF Discovery message. The MSF Discovery Extension format for
	Mobile Routers is shown below.		Mobile Routers is shown below.
	0 1 2 3		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		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 | Length |R|Pri. |L|Res. | Region_ID |		| Type | Length |R|Pri. |L|Res. | Area_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobile IPv4 Router-ID |		| Mobile IPv4 Router-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Mobile Router MSF Discovery Extension		Mobile Router MSF Discovery Extension
	Figure 6		Figure 6
	Type - 0 = MSF Discovery		Type - 0 = MSF Discovery
	Length - Length of the message in octets.		Length - Length of the message in octets.
	R - Mobile Node Type Indication. 1 = Mobile Router.		R - Mobile Node Type Indication. 1 = Mobile Router.
	Pri. - A 3-bit Priority Code (0-7).		Pri. - A 3-bit Priority Code (0-7).
	L - Always set to 0 in the MSF Discovery sent by a mobile router.		L - Always set to 0 in the MSF Discovery sent by a mobile router.
	Res. - Reserved.		Res. - Reserved.
	Region_ID - An Identifier (1-255) associated with the Regional		Area_ID - An Identifier (1-255) associated with the Area Mobility
	Mobility Route Reflector. Region_ID=0 must be used for initial		Route Reflector. Area_ID=0 must be used for initial registrations
	registrations by mobile nodes.		by mobile nodes.
	3.1.1.3. MSF Advertisement - IPv4		3.1.1.3. MSF Advertisement - IPv4
	After receiving the MSF Discovery message from a mobile host or		After receiving the MSF Discovery message from a mobile host or
	router the MSF should reply with the MSF Advertisement message using		router the MSF should reply with the MSF Advertisement message using
	extension format shown below.		extension format shown below.
	0 1 2 3		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		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 | Length | Sequence Number |		| Type | Length | Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Registration Lifetime |L|R|G|Reserved | Group ID |		| Registration Lifetime |L|R|G|Reserved | Group ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF IP Address |		| MSF IP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF Virtual Link Layer Address (first 32 bits) |		| MSF Virtual Link Layer Address (first 32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Last 16 bits | Reserved | Region_ID |		|Last 16 bits | Reserved | Area_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Correlation ID |		| Correlation ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MSF Advertisement Extension		MSF Advertisement Extension
	Figure 7		Figure 7
	Type - 1 = MSF Advertisement		Type - 1 = MSF Advertisement
	Length - Length of the message in octets.		Length - Length of the message in octets.
	Sequence Number - The sequence number of the MSF Advertisement		Sequence Number - The sequence number of the MSF Advertisement
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 5 ¶
	= 0		= 0
	MSF IP Address - Virtual IP Address of the MSF (may be different		MSF IP Address - Virtual IP Address of the MSF (may be different
	from any particular MSF LER interface IP address		from any particular MSF LER interface IP address
	MSF Virtual Link Layer Address - a MAC address shared and		MSF Virtual Link Layer Address - a MAC address shared and
	recognized by all MPLS LER interfaces participating in the MSF.		recognized by all MPLS LER interfaces participating in the MSF.
	This address may specifically be used to support Local Micro-		This address may specifically be used to support Local Micro-
	Mobility (see Section 4.3.1).		Mobility (see Section 4.3.1).
	Region_ID - An Identifier (1-255) associated with the Regional		Area_ID - An Identifier (1-255) associated with the Area Mobility
	Mobility Route Reflector. Region_ID=0 must be used for initial		Route Reflector. Area_ID=0 must be used for initial registrations
	registrations by mobile nodes.		by mobile nodes.
	Correlation ID - a number used to keep track of the registration		Correlation ID - a number used to keep track of the registration
	requests and the corresponding reply message pairs.		requests and the corresponding reply message pairs.
	The MSF Advertisement should be sent to the unicast link layer		The MSF Advertisement should be sent to the unicast link layer
	address and the unicast IP address of the mobile host or router that		address and the unicast IP address of the mobile host or router that
	were used in the MSF Discovery link layer header and the MSF		were used in the MSF Discovery link layer header and the MSF
	Discovery Extension payload respectively.		Discovery Extension payload respectively.
	Upon receipt of the MSF Advertisement mobile hosts should continue to		Upon receipt of the MSF Advertisement mobile hosts should continue to
	skipping to change at page 21, line 5 ¶		skipping to change at page 21, line 5 ¶
	3.1.2. Discovery Process - IPv6		3.1.2. Discovery Process - IPv6
	The MSF discovery process for IPv6 is identical to the discovery		The MSF discovery process for IPv6 is identical to the discovery
	process for IPv4 with the exception of the use of IPv6 specific		process for IPv4 with the exception of the use of IPv6 specific
	Router Solicitation and Advertisement messages based on ICMPv6		Router Solicitation and Advertisement messages based on ICMPv6
	[RFC4443]. These messages are specified in [RFC4861]. As in the		[RFC4443]. These messages are specified in [RFC4861]. As in the
	IPv4 case the Router Solicitation and Advertisement messages carry		IPv4 case the Router Solicitation and Advertisement messages carry
	the MLBN extensions and are termed the MSF Discovery and the MSF		the MLBN extensions and are termed the MSF Discovery and the MSF
	Advertisement respectively.		Advertisement respectively.
	0 1 2 3		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		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 |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved |		| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF Discovery Extension TLV (variable) |		| MSF Discovery Extension TLV (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IPv6 Router Solicitation with MSF Discovery Extension		IPv6 Router Solicitation with MSF Discovery Extension
	Figure 8		Figure 8
	Link Layer Fields: Destination Address - This should be the		Link Layer Fields: Destination Address - This should be the
	multicast or broadcast Link Layer Address.		multicast or broadcast Link Layer Address.
	IP Fields: Source Address - IP Address of the Mobile Host or IP		IP Fields: Source Address - IP Address of the Mobile Host or IP
	address of the interface of the Mobile Router from which this		address of the interface of the Mobile Router from which this
	message is sent.		message is sent.
	Destination Address - This is the all-routers multicast address		Destination Address - This is the all-routers multicast address
	FF02::2		FF02::2
	ICMP Fields: Type = 133 Router Solicitation.		ICMP Fields: Type = 133 Router Solicitation.
	Code = 1 MLBN MSF Discovery Extension included.		Code = 1 MLBN MSF Discovery Extension included.
	0 1 2 3		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		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 |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cur Hop Limit |M|O| Reserved | Router Lifetime |		| Cur Hop Limit |M|O| Reserved | Router Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Time |		| Reachable Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Retrans Timer |		| Retrans Timer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF Discovery Extension TLV (variable) |		| MSF Discovery Extension TLV (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IPv6 Router Advertisement with MSF Advertisement Extension		IPv6 Router Advertisement with MSF Advertisement Extension
	Figure 9		Figure 9
	Link Layer Fields: Destination Address - This should be the source		Link Layer Fields: Destination Address - This should be the source
	address used to deliver the MSF Discovery message from the mobile		address used to deliver the MSF Discovery message from the mobile
	node.		node.
	IP Fields: Source Address - IP Address of the MSF.		IP Fields: Source Address - IP Address of the MSF.
	skipping to change at page 23, line 33 ¶		skipping to change at page 23, line 33 ¶
	Full Registration messaging makes use of the UDP port RRR and may		Full Registration messaging makes use of the UDP port RRR and may
	provide a mechanism for various functional extensions. Full		provide a mechanism for various functional extensions. Full
	Registration uses two message types:		Registration uses two message types:
	Registration Request - Type 1		Registration Request - Type 1
	Registration Reply - Type 2		Registration Reply - Type 2
	The Registration Message formats are shown below.		The Registration Message formats are shown below.
	0 1 2 3		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		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 | Length |H| Rri.|ASTI | Region_ID |		| Type | Length |H| Rri.|ASTI | Area_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobile Host IPv4 Source Address |		| Mobile Host IPv4 Source Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF Address |		| MSF Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Correlation ID |		| Correlation ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extensions		| Extensions
	+-+-+-+-+-+-+....		+-+-+-+-+-+-+....
	Full Registration Request		Full Registration Request
	Figure 10		Figure 10
	Type - 1 = Full Registration Request		Type - 1 = Full Registration Request
	Length - Length of the message in octets.		Length - Length of the message in octets.
	H - Mobile Node Type Indication. 0 = Mobile Host		H - Mobile Node Type Indication. 0 = Mobile Host
	Pri. - A 3-bit priority code (0-7).		Pri. - A 3-bit priority code (0-7).
	ASTI - Application Service Type Indication. This 3-bit field may		ASTI - Application Service Type Indication. This 3-bit field may
	be used to indicate to the MSF what type of service is to be used		be used to indicate to the MSF what type of service is to be used
	by the mobile host. For example, "Internet Access Only" or Full		by the mobile host. For example, "Internet Access Only" or Full
	Mobile-to-Mobile Routing". This indication can then be mapped to		Mobile-to-Mobile Routing". This indication can then be mapped to
	the Network Update Mode Code used in the Mobility Binding		the Network Update Mode Code used in the Mobility Binding
	structure.		structure.
	Region_ID - An Identifier (1-255) associated with the Regional		Area_ID - An Identifier (1-255) associated with the Area Mobility
	Mobility Route Reflector. Region_ID=0 must be used for initial		Route Reflector. Area_ID=0 must be used for initial registrations
	registrations by mobile nodes.		by mobile nodes.
	Correlation ID - a number used to keep track of the registration		Correlation ID - a number used to keep track of the registration
	requests and the corresponding reply message pairs.		requests and the corresponding reply message pairs.
	0 1 2 3		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		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 | Length | Flags |		| Type | Length | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Registration Lifetime | Reserved | Region_ID |		| Registration Lifetime | Reserved | Area_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobile Host IPv4 Source Address |		| Mobile Host IPv4 Source Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF IP Address |		| MSF IP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF Virtual Link Layer Address (first 32 bits) |		| MSF Virtual Link Layer Address (first 32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Last 16 bits | Reserved |		|Last 16 bits | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Correlation ID |		| Correlation ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extensions		| Extensions
	+-+-+-+-+-+-+....		+-+-+-+-+-+-+....
	Full Registration Reply		Full Registration Reply
	Figure 11		Figure 11
	Type - 2 = Full Registration Reply		Type - 2 = Full Registration Reply
	Length - Length of the message in octets.		Length - Length of the message in octets.
	Flags - To be defined		Flags - To be defined
	Registration Lifetime - the time in seconds until the registration		Registration Lifetime - the time in seconds until the registration
	entry in the MSF database expires.		entry in the MSF database expires.
	Region_ID - An Identifier (1-255) associated with the Regional		Area_ID - An Identifier (1-255) associated with the Area Mobility
	Mobility Route Reflector. Region_ID=0 must be used for initial		Route Reflector. Area_ID=0 must be used for initial registrations
	registrations by mobile nodes.		by mobile nodes.
	MSF IP Address - Virtual IP Address of the MSF (may be different		MSF IP Address - Virtual IP Address of the MSF (may be different
	from any particular MSF LER interface IP address		from any particular MSF LER interface IP address
	MSF Virtual Link Layer Address - a MAC address shared and		MSF Virtual Link Layer Address - a MAC address shared and
	recognized by all MPLS LER interfaces participating in the MSF.		recognized by all MPLS LER interfaces participating in the MSF.
	This address may specifically be used to support Local Micro-		This address may specifically be used to support Local Micro-
	Mobility (see Section 4.3.1).		Mobility (see Section 4.3.1).
	Correlation ID - a number used to keep track of the registration		Correlation ID - a number used to keep track of the registration
	requests and the corresponding reply message pairs.		requests and the corresponding reply message pairs.
	3.1.3.1.3. Group Registration - IPv4		3.1.3.1.3. Group Registration - IPv4
	Clearly the discovery and registration procedure has a great effect		Clearly the discovery and registration procedure has a great effect
	on the network responsiveness especially when a mobile host moves		on the network responsiveness especially when a mobile host moves
	from one serving MSF to another. The following enhanced registration		from one serving MSF to another. The following enhanced registration
	scheme can be implemented to simplify the registrations resulting		scheme can be implemented to simplify the registrations resulting
	from the MSF-to-MSF handoff and therefore improve the network		from the MSF-to-MSF hand-off and therefore improve the network
	responsiveness. We refer to it as the Group Registration.		responsiveness. We refer to it as the Group Registration.
	The entire MPLS edge network may be divided in groups or regions		The entire MPLS edge network may be divided in groups or regions
	containing the geographically close MSF enabled LER nodes. Each		containing the geographically close MSF enabled LER nodes. Each
	group should be assigned a unique Group ID (1-255). The mobile host		group should be assigned a unique Group ID (1-255). The mobile host
	will register with a LER node within a group using a Group		will register with a LER node within a group using a Group
	Registration procedure. The LER node will distribute the		Registration procedure. The LER node will distribute the
	registration information to the rest of the group members using the		registration information to the rest of the group members using the
	established MP-BGP peering sessions. These messages may be coded as		established MP-BGP peering sessions. These messages may be coded as
	another type of the NLRI in the Address Family structure. The size		another type of the NLRI in the Address Family structure. The size
	skipping to change at page 27, line 8 ¶		skipping to change at page 27, line 8 ¶
	must transition to the Group Registration protocol using the same UDP		must transition to the Group Registration protocol using the same UDP
	port RRR as for the Full Registration.		port RRR as for the Full Registration.
	Group Registration uses two message types:		Group Registration uses two message types:
	Group Registration Request - Type 3		Group Registration Request - Type 3
	Group Registration Reply - Type 4		Group Registration Reply - Type 4
	The Group Registration Message formats are shown below.		The Group Registration Message formats are shown below.
	0 1 2 3		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		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 | Length |H| Rri.|ASTI |G| Group ID |		| Type | Length |H| Rri.|ASTI |G| Group ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobile Host IPv4 Source Address |		| Mobile Host IPv4 Source Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSF Address |		| MSF Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Correlation ID |		| Correlation ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Region_ID | Extensions		| Area_ID | Extensions
	+-+-+-+-+-+-+-+-+-+-+-+-+-+....		+-+-+-+-+-+-+-+-+-+-+-+-+-+....
	Group Registration Request		Group Registration Request
	Figure 12		Figure 12
	Type - 3 = Group Registration Request		Type - 3 = Group Registration Request
	Length - Length of the message in octets.		Length - Length of the message in octets.
	H - Mobile Node Type Indication. 0 = Mobile Host		H - Mobile Node Type Indication. 0 = Mobile Host
	skipping to change at page 28, line 5 ¶		skipping to change at page 28, line 5 ¶
	structure.		structure.
	G - Group Registration Requested (1)		G - Group Registration Requested (1)
	Group ID - Unique Registration Group Number. Should be zero if G		Group ID - Unique Registration Group Number. Should be zero if G
	= 0		= 0
	Correlation ID - a number used to keep track of the registration		Correlation ID - a number used to keep track of the registration
	requests and the corresponding reply message pairs.		requests and the corresponding reply message pairs.
	Region_ID - An Identifier (1-255) associated with the Regional		Area_ID - An Identifier (1-255) associated with the Area Mobility
	Mobility Route Reflector. Region_ID=0 must be used for initial		Route Reflector. Area_ID=0 must be used for initial registrations
	registrations by mobile nodes.		by mobile nodes.
	0 1 2 3		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		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 | Length | Flags |		| Type | Length | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Registration Lifetime |G| Reserved | Group ID |		| Registration Lifetime |G| Reserved | Group ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobile Host IPv4 Source Address |		| Mobile Host IPv4 Source Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Virtual IP Address |		| Group Virtual IP Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group Virtual Link Layer Address (first 32 bits) |		| Group Virtual Link Layer Address (first 32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Last 16 bits | Reserved |		|Last 16 bits | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Correlation ID |		| Correlation ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Region_ID | Extensions		| Area_ID | Extensions
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....
	Group Registration Reply		Group Registration Reply
	Figure 13		Figure 13
	Type - 4 = Group Registration Reply		Type - 4 = Group Registration Reply
	Length - Length of the message in octets.		Length - Length of the message in octets.
	Flags - To be defined		Flags - To be defined
	skipping to change at page 29, line 14 ¶		skipping to change at page 29, line 14 ¶
	Group Virtual Link Layer Address - a MAC address shared and		Group Virtual Link Layer Address - a MAC address shared and
	recognized by all MPLS LER interfaces of all MSF's that belong to		recognized by all MPLS LER interfaces of all MSF's that belong to
	the Registration Group identified by the Group ID. This address		the Registration Group identified by the Group ID. This address
	may specifically be used to support Group Micro-Mobility (see		may specifically be used to support Group Micro-Mobility (see
	Section 4.3.2).		Section 4.3.2).
	Correlation ID - a number used to keep track of the registration		Correlation ID - a number used to keep track of the registration
	requests and the corresponding reply message pairs.		requests and the corresponding reply message pairs.
	Region_ID - An Identifier (1-255) associated with the Regional		Area_ID - An Identifier (1-255) associated with the Area Mobility
	Mobility Route Reflector. Region_ID=0 must be used for initial		Route Reflector. Area_ID=0 must be used for initial registrations
	registrations by mobile nodes.		by mobile nodes.
	As in the Full Registration case the Group Registration allows to		As in the Full Registration case the Group Registration allows to
	perform additional functions as part of the registration process by		perform additional functions as part of the registration process by
	means of using the functional extensions. An example of such a		means of using the functional extensions. An example of such a
	function is the Mobile Host Authentication.		function is the Mobile Host Authentication.
	After the completion of the Group Registration with the initial MSF		After the completion of the Group Registration with the initial MSF
	that is part of the Registration Group, the mobile host must send the		that is part of the Registration Group, the mobile host must send the
	MSF Discovery messages destined to the Group Virtual Link Layer		MSF Discovery messages destined to the Group Virtual Link Layer
	Address listing the Group ID and the Group Virtual IP Address. The		Address listing the Group ID and the Group Virtual IP Address. The
	skipping to change at page 31, line 17 ¶		skipping to change at page 31, line 17 ¶
	are defined. Specifically the following new AFI values are defined:		are defined. Specifically the following new AFI values are defined:
	Mobility IPv4 Unicast - AFI X1 SAFI Y1		Mobility IPv4 Unicast - AFI X1 SAFI Y1
	Mobility IPv6 Unicast - AFI X2 SAFI Y1		Mobility IPv6 Unicast - AFI X2 SAFI Y1
	The MP_REACH_NLRI attribute is used to update the LER nodes with new		The MP_REACH_NLRI attribute is used to update the LER nodes with new
	Mobility Binding information. The structure of the attribute is		Mobility Binding information. The structure of the attribute is
	shown below.		shown below.
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Address Family Identifier (2 octets) |		| Address Family Identifier (2 octets) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Subsequent Address Family Identifier (1 octet) |		| Subsequent Address Family Identifier (1 octet) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Length of Next Hop Network Address (1 octet) |		| Length of Next Hop Network Address (1 octet) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Network Address of Next Hop (variable) |		| Network Address of Next Hop (variable) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Reserved (1 octet) |		| Reserved (1 octet) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Mobility Binding (NLRI) Information (variable) |		| Mobility Binding (NLRI) Information (variable) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	MP_REACH_NLRI with Mobility Binding		MP_REACH_NLRI with Mobility Binding
	Figure 14		Figure 14
	The MP_UNREACH_NLRI attribute is used to withdraw the Mobility		The MP_UNREACH_NLRI attribute is used to withdraw the Mobility
	Binding information. The structure of the attribute is shown below.		Binding information. The structure of the attribute is shown below.
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Address Family Identifier (2 octets) |		| Address Family Identifier (2 octets) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Subsequent Address Family Identifier (1 octet) |		| Subsequent Address Family Identifier (1 octet) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Mobility Binding (Withdrawn Routes) (variable) |		| Mobility Binding (Withdrawn Routes) (variable) |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	MP_UNREACH_NLRI with Mobility Binding		MP_UNREACH_NLRI with Mobility Binding
	Figure 15		Figure 15
	The Mobility Binding itself is encoded in the NLRI format shown		The Mobility Binding itself is encoded in the NLRI format shown
	below.		below.
	+---------------------------+		+---------------------------+
	| Length (1 octet) |		| Length (1 octet) |
	+---------------------------+		+---------------------------+
	|Mobility Binding (variable)|		|Mobility Binding (variable)|
	+---------------------------+		+---------------------------+
	NLRI Encoding for Mobility Bindings		NLRI Encoding for Mobility Bindings
	Figure 16		Figure 16
	For the definitions of the fields in the above figures (with the		For the definitions of the fields in the above figures (with the
	exception of the Mobility Binding related information) please see		exception of the Mobility Binding related information) please see
	[RFC4760].		[RFC4760].
	3.2.2. Mobility Bindings		3.2.2. Mobility Bindings
	skipping to change at page 32, line 34 ¶		skipping to change at page 32, line 34 ¶
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Origin MP-BGP NEXT_HOP |		| Origin MP-BGP NEXT_HOP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Target MP-BGP NEXT_HOP |		| Target MP-BGP NEXT_HOP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobile Host Address |		| Mobile Host Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|H| UT |Res. | Mobility Label |Pri. |S|		|H| UM | UT | Mobility Label |Pri. |S|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Area_ID |
			+-+-+-+-+-+-+-+-+
	NLRI Encoding for the Host Mobility Binding		NLRI Encoding for the Host Mobility Binding
	Figure 17		Figure 17
	Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the		Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the
	Mobility Binding. This address may be carried in the IPv4 or IPv6		Mobility Binding. This address may be carried in the IPv4 or IPv6
	format depending on the {AFI, SAFI} pair used.		format depending on the {AFI, SAFI} pair used.
	Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the		Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the
	skipping to change at page 33, line 11 ¶		skipping to change at page 33, line 13 ¶
	Unsolicited Downstream Push this field should be set to 0. This		Unsolicited Downstream Push this field should be set to 0. This
	address may be carried in the IPv4 or IPv6 format depending on the		address may be carried in the IPv4 or IPv6 format depending on the
	{AFI, SAFI} pair used.		{AFI, SAFI} pair used.
	Mobile Host Address - IPv4 or IPv6 Address of the mobile host.		Mobile Host Address - IPv4 or IPv6 Address of the mobile host.
	This address may be carried in the IPv4 or IPv6 format depending		This address may be carried in the IPv4 or IPv6 format depending
	on the {AFI, SAFI} pair used.		on the {AFI, SAFI} pair used.
	H - Mobile Node Type Indication. 0 = Mobile Host		H - Mobile Node Type Indication. 0 = Mobile Host
	UT - Update Type. This 3-bit code is mapped to the ASTI code in		UM - Update Mode. This 3-bit code is mapped to the ASTI code in
	the MSF Discovery and Registration Request messages to indicate		the MSF Discovery and Registration Request messages to indicate
	the Network Update Mode selection (see Section 4).		the Network Update Mode selection (see Section 4).
	Res. - Reserved.		UT - Update Type. This 4-bit code is used to indicate the
			Mobility Update Type (internal, external, inter-carrier - see
			Section 4).
	Mobility Label - Overlay MPLS Label (20 bits) associated with the		Mobility Label - Overlay MPLS Label (20 bits) associated with the
	IP address of the mobile host in the MSF database.		IP address of the mobile host in the MSF database.
	Pri. - A 3-bit priority code (0-7).		Pri. - A 3-bit priority code (0-7).
	S - Bottom of Stack.		S - Bottom of Stack.
			Area_ID - An Identifier (1-255) associated with the Area Mobility
			Route Reflector.
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Origin MP-BGP NEXT_HOP |		| Origin MP-BGP NEXT_HOP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Target MP-BGP NEXT_HOP |		| Target MP-BGP NEXT_HOP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobile Router ID |		| Mobile Router ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|R| UT | Res. |No of Prefixes | IP Prefix 1 |		|R| UM | UT |No of Prefixes | IP Prefix 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP Prefix 1 | Prefix 1 Len. | Variable No. |		| IP Prefix 1 | Prefix 1 Len. | Variable No. |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| of Prefixes/Len |		| of Prefixes/Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mobility Label |Pri. |S|		| Mobility Label |Pri. |S| Area_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	NLRI Encoding for the Router Mobility Binding		NLRI Encoding for the Router Mobility Binding
	Figure 18		Figure 18
	Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the		Origin MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the
	Mobility Binding. This address may be carried in the IPv4 or IPv6		Mobility Binding. This address may be carried in the IPv4 or IPv6
	format depending on the {AFI, SAFI} pair used.		format depending on the {AFI, SAFI} pair used.
	Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the		Target MP-BGP NEXT_HOP - Router ID of the MPLS LER to receive the
	skipping to change at page 34, line 17 ¶		skipping to change at page 34, line 43 ¶
	Unsolicited Downstream Push this field should be set to 0. This		Unsolicited Downstream Push this field should be set to 0. This
	address may be carried in the IPv4 or IPv6 format depending on the		address may be carried in the IPv4 or IPv6 format depending on the
	{AFI, SAFI} pair used.		{AFI, SAFI} pair used.
	Mobile Router ID - IP Address of the mobile router. This address		Mobile Router ID - IP Address of the mobile router. This address
	may be carried in the IPv4 or IPv6 format depending on the {AFI,		may be carried in the IPv4 or IPv6 format depending on the {AFI,
	SAFI} pair used.		SAFI} pair used.
	R - Mobile Node Type Indication. 1 = Mobile Router		R - Mobile Node Type Indication. 1 = Mobile Router
	UT - Update Type. This 3-bit code is mapped to the ASTI code in		UM - Update Type. This 3-bit code is mapped to the ASTI code in
	the MSF Discovery and Registration Request messages to indicate		the MSF Discovery and Registration Request messages to indicate
	the Network Update Mode selection (see Section 4).		the Network Update Mode selection (see Section 4).
	Res. - Reserved.		UT - Update Type. This 4-bit code is used to indicate the
			Mobility Update Type (internal, external, inter-carrier - see
			Section 4).
	No. of Prefixes - Number of IP Prefixes carried in this Mobility		No. of Prefixes - Number of IP Prefixes carried in this Mobility
	Binding.		Binding.
	IP Prefix 1 - First IP Prefix (32 bits for IPv4, 128 bits for		IP Prefix 1 - First IP Prefix (32 bits for IPv4, 128 bits for
	IPv6)		IPv6)
	Prefix 1 Len. - Length (in number of bits) of the network part of		Prefix 1 Len. - Length (in number of bits) of the network part of
	IP Prefix 1		IP Prefix 1
	Mobility Label - Overlay MPLS Label (20 bits) associated with each		Mobility Label - Overlay MPLS Label (20 bits) associated with each
	of the IP Prefixes served by the mobile router in the MSF database		of the IP Prefixes served by the mobile router in the MSF database
	of the originating LER.		of the originating LER.
	S - Bottom of Stack.		S - Bottom of Stack.
			Area_ID - An Identifier (1-255) associated with the Area Mobility
			Route Reflector.
	The receiving MSF must read the R flag in the Mobility Binding and		The receiving MSF must read the R flag in the Mobility Binding and
	associate the provided Mobility Label with each of the IP prefixes		associate the provided Mobility Label with each of the IP prefixes
	found in the body of the Mobility Binding. The derived associations		found in the body of the Mobility Binding. The derived associations
	must be installed in the MPLS forwarding table of the MPLS LER and in		must be installed in the MPLS forwarding table of the MPLS LER and in
	turn associated with the infrastructure label assigned to the "Origin		turn associated with the infrastructure label assigned to the "Origin
	MP-BGP NEXT_HOP" address indicated in the received Mobility Binding		MP-BGP NEXT_HOP" address indicated in the received Mobility Binding
	3.2.3. Group Registration Management with MP-BGP		3.2.3. Group Registration Management with MP-BGP
	The Group Registration (Section 3.1.3.1.3) information obtained via		The Group Registration (Section 3.1.3.1.3) information obtained via
	skipping to change at page 37, line 19 ¶		skipping to change at page 38, line 10 ¶
	The {AFI, SAFI} pairs defined in this document for mobility		The {AFI, SAFI} pairs defined in this document for mobility
	management must be supported by all BGP speakers participating in		management must be supported by all BGP speakers participating in
	mobility management. A BGP Capability Advertisement as specified in		mobility management. A BGP Capability Advertisement as specified in
	[RFC4760] must be used by the BGP speakers to ensure compatibility.		[RFC4760] must be used by the BGP speakers to ensure compatibility.
	3.3. Mobile Application Priority Indication and Recognition		3.3. Mobile Application Priority Indication and Recognition
	Given the sensitivity of applications to the network service		Given the sensitivity of applications to the network service
	disruption the MSF function should include a mechanism by which an		disruption the MSF function should include a mechanism by which an
	application may indicate the level of tolerance to the disruption due		application may indicate the level of tolerance to the disruption due
	to the network handling of the handoff process. This indication may		to the network handling of the hand-off process. This indication may
	be encoded in the registration messaging payload and then		be encoded in the registration messaging payload and then
	incorporated into the Mobility Binding protocol structure. The		incorporated into the Mobility Binding protocol structure. The
	application sensitivity prioritization scheme may be used to control		application sensitivity prioritization scheme may be used to control
	the Mobility Binding processing priority during the distribution		the Mobility Binding processing priority during the distribution
	process. For example a mobile host running a real time interactive		process. For example a mobile host running a real time interactive
	application may be given a higher processing priority over the mobile		application may be given a higher processing priority over the mobile
	host running an elastic data transfer application. The		host running an elastic data transfer application. The
	prioritization of processing leads to a differential treatment of the		prioritization of processing leads to a differential treatment of the
	mobile application at various processing points of the mobile network		mobile application at various processing points of the mobile network
	such as the ingress MSF, the intermediate hierarchical route		such as the ingress MSF, the intermediate hierarchical route
	skipping to change at page 39, line 7 ¶		skipping to change at page 40, line 7 ¶
	Network Update Type Code used in the Mobility Binding structure. For		Network Update Type Code used in the Mobility Binding structure. For
	example, if ASTI code 001 (binary) is used to indicate the "Internet		example, if ASTI code 001 (binary) is used to indicate the "Internet
	Access Only" service, the local MSF may use the Selective Downstream		Access Only" service, the local MSF may use the Selective Downstream
	Push (see Section 4.1.2) Network Update mode. In addition the MSF		Push (see Section 4.1.2) Network Update mode. In addition the MSF
	may include the corresponding Update Type code in the Mobility		may include the corresponding Update Type code in the Mobility
	Binding structure in order to indicate to the Mobility Route		Binding structure in order to indicate to the Mobility Route
	Reflectors that the Selective Downstream Push is to be used.		Reflectors that the Selective Downstream Push is to be used.
	4. Network Update and Hand-off Processing		4. Network Update and Hand-off Processing
	4.1. Network Update Modes		4.1. Network Update Modes and Types
	The following four modes for the Mobility Binding Distribution or		The following four modes for the Mobility Binding Distribution or
	Withdrawal are proposed: i) unsolicited downstream push, ii)		Withdrawal are proposed: i) unsolicited downstream push, ii)
	selective downstream push, iii) predictive downstream push, and iv)		selective downstream push, iii) predictive downstream push, and iv)
	hierarchical on-demand distribution.		hierarchical on-demand distribution.
	4.1.1. Unsolicited Downstream Push		4.1.1. Unsolicited Downstream Push Mode
	In this mode the originating LER node updates all other MSF enabled		In this mode the originating LER node updates all other MSF enabled
	LER nodes that are directly peered with it. In case of a		LER nodes that are directly peered with it. In case of a
	hierarchical topology the originating LER node sends a MP-BGP update		hierarchical topology the originating LER node sends a MP-BGP update
	with the Mobility Binding information to a Route Reflector which in		with the Mobility Binding information to a Route Reflector which in
	turn updates all of the participating MSF enabled LER Route Reflector		turn updates all of the participating MSF enabled LER Route Reflector
	clients. Thus the network wide update can only considered to be		clients. Thus the network wide update can only considered to be
	complete if and only if all of the MSF LER nodes are updated.		complete if and only if all of the MSF LER nodes are updated.
	Clearly this distribution mode has scalability limitations and may be		Clearly this distribution mode has scalability limitations and may be
	applicable for a relatively small number of the MSF enabled LER		applicable for a relatively small number of the MSF enabled LER
	nodes. The Update Type Code for this mode is binary 000.		nodes. The Update Mode Code for this mode is binary 000.
	4.1.2. Selective Downstream Push		4.1.2. Selective Downstream Push Mode
	In this mode the Mobility Binding updates are only sent to a select		In this mode the Mobility Binding updates are only sent to a select
	set of the MSF enabled LER nodes. The underlying idea for this mode		set of the MSF enabled LER nodes. The underlying idea for this mode
	is that it is very likely that the most used destinations from the		is that it is very likely that the most used destinations from the
	mobile host when it communicates with the Internet are the		mobile host when it communicates with the Internet are the
	destinations reachable via a finite set of the service provider's		destinations reachable via a finite set of the service provider's
	Internet gateway nodes which are in turn reachable via a finite set		Internet gateway nodes which are in turn reachable via a finite set
	of the MSF enabled LER nodes. As such, when a mobile host registers		of the MSF enabled LER nodes. As such, when a mobile host registers
	with the serving MSF, instead of using the Unsolicited Downstream		with the serving MSF, instead of using the Unsolicited Downstream
	Push to all LER nodes, the Mobility Binding update for this mobile		Push to all LER nodes, the Mobility Binding update for this mobile
	host would be sent to a finite set of the LER nodes connected to the		host would be sent to a finite set of the LER nodes connected to the
	service provider Internet gateways. This mode can be used for the		service provider Internet gateways. This mode can be used for the
	initial update process and the Unsolicited Downstream Push can be		initial update process and the Unsolicited Downstream Push can be
	used at a later point in time. The Update Type Code for this mode is		used at a later point in time. The Update Type Mode for this mode is
	binary 001.		binary 001.
	4.1.3. Predictive Downstream Push		4.1.3. Predictive Downstream Push Mode
	In this mode the Mobility Binding updates are sent to those MSF		In this mode the Mobility Binding updates are sent to those MSF
	enabled LER nodes which are identified as a NEXT_HOP for the FEC (and		enabled LER nodes which are identified as a NEXT_HOP for the FEC (and
	the corresponding LSP) leading to the destination of the packet		the corresponding LSP) leading to the destination of the packet
	originated by a mobile node. This mode is based on the fact that if		originated by a mobile node. This mode is based on the fact that if
	the destination FEC exists in the serving MSF LER's routing table,		the destination FEC exists in the serving MSF LER's routing table,
	and the mobile node sends a packet to the FEC, the LER will perform		and the mobile node sends a packet to the FEC, the LER will perform
	the label imposition (for the infrastructure label) by selecting the		the label imposition (for the infrastructure label) by selecting the
	label corresponding to the FEC NEXT_HOP. This NEXT_HOP in turn		label corresponding to the FEC NEXT_HOP. This NEXT_HOP in turn
	identifies the destination MSF enabled LER node to which the Mobility		identifies the destination MSF enabled LER node to which the Mobility
	Binding update needs to be sent. The predictive feature of this mode		Binding update needs to be sent. The predictive feature of this mode
	comes from the fact that the Mobility Binding update destination is		comes from the fact that the Mobility Binding update destination is
	predicted as the result of the originating LER's lookup of the		predicted as the result of the originating LER's lookup of the
	destination FEC and its NEXT_HOP. Clearly it is likely that the LER		destination FEC and its NEXT_HOP. Clearly it is likely that the LER
	node to which the predictive Mobility Binding update is sent may		node to which the predictive Mobility Binding update is sent may
	receive the reply packet from the mobile node's destination before		receive the reply packet from the mobile node's destination before
	the Mobility Binding for the originating host is received. In this		the Mobility Binding for the originating host is received. In this
	case the LER that is being updated may buffer the reply packet for a		case the LER that is being updated may buffer the reply packet for a
	reasonable period of time to wait for the mobility update. The		reasonable period of time to wait for the mobility update. The
	Update Type Code for this mode is binary 010.		Update Mode Code for this mode is binary 010.
	4.1.4. Hierarchical On-Demand Distribution		4.1.4. Hierarchical On-Demand Distribution Mode
	The Mobility Binding update is first sent by a serving MSF LER to a		The Mobility Binding update is first sent by a serving MSF LER to a
	set of Mobility Route Reflectors using the Selective Downstream Push.		set of Mobility Route Reflectors using the Selective Downstream Push.
	Once the Mobility Route Reflectors have been updated, all other LER		Once the Mobility Route Reflectors have been updated, all other LER
	nodes must explicitly request Mobility Labels from the Mobility Route		nodes must explicitly request Mobility Labels from the Mobility Route
	Reflectors for packets destined to a mobile node. The Update Type		Reflectors for packets destined to a mobile node. The Update Mode
	Code for this mode is binary 011.		Code for this mode is binary 011.
	4.1.4.1. On-Demand Requests for Mobility Binding Information		4.1.4.1. On-Demand Requests for Mobility Binding Information
	To support the Hierarchical On-Demand Distribution Network Update		To support the Hierarchical On-Demand Distribution Network Update
	Mode the following explicit Mobility Binding information request		Mode the following explicit Mobility Binding information request
	procedure based on MP-BGP may be used. When a MPLS LER supporting		procedure based on MP-BGP may be used. When a MPLS LER supporting
	MPLS Mobility receives an IP packet, it first should check if the		MPLS Mobility receives an IP packet, it first should check if the
	Destination Address listed in the IP header belongs to the overall IP		Destination Address listed in the IP header belongs to the overall IP
	address range assigned to the mobility functions and the		address range assigned to the mobility functions and the
	skipping to change at page 41, line 19 ¶		skipping to change at page 42, line 19 ¶
	Mobility IPv6 Unicast - AFI X2 SAFI Y3		Mobility IPv6 Unicast - AFI X2 SAFI Y3
	The NLRI encoding is shown below:		The NLRI encoding is shown below:
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MP-BGP NEXT_HOP |		| MP-BGP NEXT_HOP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Request Type | Region_ID | Number of Addresses |		|Request Type | Area_ID | Number of Addresses |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP Destination Address |		| IP Destination Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP Destination Address		| IP Destination Address
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
	NLRI Encoding for On-Demand Mobility Binding Request		NLRI Encoding for On-Demand Mobility Binding Request
	Figure 20		Figure 20
	MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On-		MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On-
	Demand Mobility Binding Information Request. This address may be		Demand Mobility Binding Information Request. This address may be
	carried in the IPv4 or IPv6 format depending on the {AFI, SAFI}		carried in the IPv4 or IPv6 format depending on the {AFI, SAFI}
	pair used.		pair used.
	Request Type - To be defined (may be "Specific, Partial, ALL or		Request Type - To be defined (may be "Specific, Partial, ALL or
	LRL").		LRL").
	Region_ID - An Identifier (1-255) associated with the Regional		Area_ID - An Identifier (1-255) associated with the Area Mobility
	Mobility Route Reflector. Region_ID=0 must be used for initial		Route Reflector. Area_ID=0 must be used for initial registrations
	registrations by mobile nodes.		by mobile nodes.
	Number of Addresses - Number of IP Destination Addresses listed in		Number of Addresses - Number of IP Destination Addresses listed in
	the On-Demand Request for which the Mobility Binding Information		the On-Demand Request for which the Mobility Binding Information
	is requested		is requested
	IP Destination Address - The IPv4 or IPv6 address of a mobile host		IP Destination Address - The IPv4 or IPv6 address of a mobile host
	for which the Mobility Binding Information is requested.		for which the Mobility Binding Information is requested.
	If the Request Type is not equal to LRL - Last Requestor List, the		If the Request Type is not equal to LRL - Last Requestor List, the
	Mobility Route Reflector (mRR) should reply with a regular Mobility		Mobility Route Reflector (mRR) should reply with a regular Mobility
	skipping to change at page 42, line 18 ¶		skipping to change at page 43, line 18 ¶
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MP-BGP NEXT_HOP |		| MP-BGP NEXT_HOP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Request Type | Reserved | Number of Addresses |		|Request Type | Reserved | Number of Addresses |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LRL Length | IP Destination + |		| LRL Length | IP Destination + |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address | Last Requestor + |		| Address | Last Requestor + |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router_ID |L.R. Region_ID | Last + |		| Router_ID | L.R. Area_ID | Last + |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Requestor Router_ID |L.R. Region_ID | LRL + |		| Requestor Router_ID | L.R. Area_ID | LRL + |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | IP Destination + |		| Length | IP Destination + |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address | Last Requestor + |		| Address | Last Requestor + |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router_ID |L.R. Region_ID |		| Router_ID | L.R. Area_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
	NLRI Encoding for On-Demand LRL Reply		NLRI Encoding for On-Demand LRL Reply
	Figure 21		Figure 21
	MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On-		MP-BGP NEXT_HOP - Router ID of the MPLS LER originating the On-
	Demand LRL Reply. This address may be carried in the IPv4 or IPv6		Demand LRL Reply. This address may be carried in the IPv4 or IPv6
	format depending on the {AFI, SAFI} pair used.		format depending on the {AFI, SAFI} pair used.
	skipping to change at page 43, line 5 ¶		skipping to change at page 44, line 5 ¶
	Number of Addresses - LRL's in the reply		Number of Addresses - LRL's in the reply
	IP Destination Address - The IPv4 or IPv6 address of a mobile host		IP Destination Address - The IPv4 or IPv6 address of a mobile host
	for which the LRL Information is requested.		for which the LRL Information is requested.
	Last Requestor Router_ID - IP Address of the LER from which the		Last Requestor Router_ID - IP Address of the LER from which the
	On-Demand Mobility Binding Information Request for the mobile node		On-Demand Mobility Binding Information Request for the mobile node
	in question was last received (may be more than one).		in question was last received (may be more than one).
	L.R. Region_ID - ID of the Regional mRR serving the LER from which		L.R. Area_ID - ID of the Area mRR serving the LER from which the
	the On-Demand Mobility Binding Information Request for the mobile		On-Demand Mobility Binding Information Request for the mobile node
	node in question was last received (may be more than one).		in question was last received (may be more than one).
	4.1.5. Network Hierarchy Considerations		4.1.5. Network Update Types
			The network update types are carried within the Mobility Binding
			structure and are used in the hierarchical mobility management
			environment to indicate the nature of the update and the subsequent
			processing behavior by the appropriate network elements such as the
			Area Mobility Route Reflector (AMRR), Area Label Edge Router (ALER)
			and the Label Edge Router (LER). Please see section Section 4.1.6.
			4.1.5.1. Internal Update Type
			An internal update is initiated by an LER node local to a Mobility
			Area and carries the Mobility Binding information for a locally
			registered mobile device. The internal update is sent by an LER to
			the AMRR in order to update the ALER node. The internal update may
			also be sent by the ALER node to AMRR in response to the external
			update received by the ALER about the Mobility Bindings originating
			outside a local area. The Update Type Code for the Internal Update
			is binary 0000.
			4.1.5.2. External Update Type
			An external update is originated by the ALER in response to an
			internal update and is sent to the AMRR. The Update Type Code for
			the External Update is binary 0001.
			4.1.6. Network Hierarchy Considerations
	The first three update modes are directly applicable for the flat MSF		The first three update modes are directly applicable for the flat MSF
	LER peering topology and the fourth to the hierarchical peering		LER peering topology and the fourth to the hierarchical peering
	environment. In the hierarchical peering environment only		environment. In the hierarchical peering environment only
	Unsolicited Downstream Push does not require any modifications to the		Unsolicited Downstream Push does not require any modifications to the
	Route Reflector operation. The Selective and Predictive modes		Route Reflector operation. The Selective and Predictive modes
	require that the Route Reflectors perform selective MP-BGP updates		require that the Route Reflectors perform selective MP-BGP updates
	for the Mobility Bindings distribution. This can be achieved by a		for the Mobility Bindings distribution. This can be achieved by a
	modification of the Route Reflector update process where destinations		modification of the Route Reflector update process where destinations
	of the selective updates indicated by the Update Type Code can be		of the selective updates indicated by the Update Mode Code can be
	derived from the "Target NEXT_HOP" parameter in the Mobility Binding		derived from the "Target NEXT_HOP" parameter in the Mobility Binding
	structure. The Hierarchical On-Demand mode requires the Route		structure. The Hierarchical On-Demand mode requires the Route
	Reflectors to store the Mobility Bindings and respond to the on-		Reflectors to store the Mobility Bindings and respond to the on-
	demand Mobility Binding requests initiated by the client MSF LER		demand Mobility Binding requests initiated by the client MSF LER
	nodes or other Mobility Route Reflectors.		nodes or other Mobility Route Reflectors.
	4.1.6. Regionalization and Scalability		4.1.7. Regionalization and Scalability
	To improve the scalability of the network update process the entire		To improve the scalability of the network update process the entire
	serving network may be divided into the Registration Regions. Each		serving network may be divided into the Mobility Areas. Each
	registration region is served by a Regional Mobility Route Reflector		Mobility Area is served by an Area Mobility Route Reflector (AMRR)
	(mRR) with the individual MSF LER nodes falling within the region		and optionally with an Area LER, with the individual MSF LER nodes
	serving as the Route Reflector Clients. Each MSF LER node in turn		falling within the area and acting as the Route Reflector Clients.
	may serve a specific geographic area called a Mobility Region that is		Each MSF LER node in turn may serve a specific geographic region
	covered by a given set of Radio Access Networks using Direct or In-		called a Mobility Region that is covered by a given set of Radio
	direct Attachment options. This type of the regionalized mobility		Access Networks using Direct or In-direct Attachment options. This
	signaling infrastructure is referred to as the Mobility Information		type of the hierarchical regionalized mobility signaling
	Location System (MILS) and is shown in the figure below.		infrastructure is referred to as the Hierarchical Mobility Label
			Based Network (H-MLBN) and is shown in the figure below.
	mRR1 mRR3		AMRR1/ALER1 AMRR3/ALER3
	+----+ +----+		+----+ +----+
	| +------------------+ `.		| +------------------+ `.
	.++-+-+ mRR2 +--+-\ `.		.++-+-+ AMRR2/ALER2 +--+-\ `.
	.'//| | +----+ | |`. \		.'//| | +----+ | |`. \
	.' /| | +--------+ +---------+ |\ \ `.		.' /| | +--------+ +---------+ |\ \ `.
	Registration Region 1 ++++-\ Registration region 4		Mobility Area 1 ++++-\ Mobility Area 3
	.' / / | /\ \ `. | \ \ `.		.' / / | /\ \ `. | \ \ `.
	.' / | | Registration region 2 | \ `. `.		.' / | | Mobility Area 2 | \ `. `.
	+-.' / +-/ | / | \ \ | | \ \		+-.' / +-/ | / | \ \ | | \ \
	+-+ +-/ +-+ +-\ | \ \ \ \-+ \ `.-+`.		+-+ +-/ +-+ +-\ | \ \ \ \-+ \ `.-+`.
	LER11 +-+ LER13+-+ +-/ | \-+ `. +-+ \-+ +-+ +`.		LER11 +-+ LER13+-+ +-/ | \-+ `. +-+ \-+ +-+ +`.
	. LER12 . LER14 +-+ +-\ +-+ +-\ LER31 +-+ LER33+-+		. LER12 . LER14 +-+ +-\ +-+ +-\ LER31 +-+ LER33+-+
	/ \ . / \ . LER21 +-+ LER23+-+ . LER32 . LER34		/ \ . / \ . LER21 +-+ LER23+-+ . LER32 . LER34
	; : / \ ; : / \ . LER22 . LER24 / \ . / \ .		; : / \ ; : / \ . LER22 . LER24 / \ . / \ .
	|11 | ;12 :|13 |;14 : / \ . / \ . ; : / \ ; : / \		|11 | ;12 :|13 |;14 : / \ . / \ . ; : / \ ; : / \
	| | | || || | ;21 : / \ ; : / \ |31 |;32 :|33 |;34 :		| | | || || | ;21 : / \ ; : / \ |31 |;32 :|33 |;34 :
	|++ | | || || | | | ;22 :|23 |;24 : | || || || |		|++ | | || || | | | ;22 :|23 |;24 : | || || || |
	:++MN | |: ;| | | | | || || | | || || || |		:++MN | |: ;| | | | | || || | | || || || |
	\ / : ; \ / : ; | | | || || | : ;| |: ;|++ |		\ / : ; \ / : ; | | | || || | : ;| |: ;|++ |
	' \ / ' \ / : ; | |: ;| | \ / : ; \ / :++CN		' \ / ' \ / : ; | |: ;| | \ / : ; \ / :++CN
	' ' \ / : ; \ / : ; ' \ / ' \ /		' ' \ / : ; \ / : ; ' \ / ' \ /
	' \ / ' \ / ' '		' \ / ' \ / ' '
	' '		' '
	Mobility Regions		Mobility Regions
	Regionalized Mobility Information Location System		Hierarchical Mobility Label Based Network (H-MLBN)
	Figure 22		Figure 22
	4.1.6.1. Mobility Information Location System (MILS)		4.1.7.1. Hierarchical Mobility Label Based Network (H-MLBN)
	The operation of MILS is based on the Hierarchical On-Demand Network		The operation of H-MLBN is based on the Hierarchical On-Demand
	Update mode and requires the individual MSF LER nodes to only		Network Update mode and requires the individual MSF LER nodes to only
	directly update their respective Regional Mobility Route Reflectors		directly update their respective Area Mobility Route Reflectors
	(using the Selective Update). After the Regional mRR's have been		(using the Selective Update Mode and the Internal Update Type).
	updated with the Mobility Binding information, these bindings may be		After the Area mRR's have been updated with the Mobility Binding
	explicitly requested by the MSF LER's in the same Registration Region		information, these bindings may be explicitly requested by the MSF
	or the LER's in other regions via their mRR's. To facilitate the		LER's in the same Mobility Area or the LER's in other areas via their
	hand-off process a Last Requestor List (LRL) is introduced and		Area mRR's. To facilitate the hand-off process a Last Requestor List
	associated with each Mobility Binding at the Regional mRR level. The		(LRL) is introduced and associated with each Mobility Binding at the
	LRL is a list of 2-tuples where each 2-tuple consists of the		Area mRR level. The LRL is a list of 2-tuples where each 2-tuple
	Router_ID and Region_ID of the MSF LER nodes that have requested		consists of the Router_ID and Area_ID of the AMRR nodes that have
	Mobility Binding information for a particular mobile node. The		requested Mobility Binding information for a particular mobile node.
	logical operation of MILS is described below based on Figure 22.		The logical operation of H-MLBN is described below based on
			Figure 22.
	1. Assume that a previously unknown MN initiated a Discovery and		1. Assume that a previously unknown MN initiated a Discovery and
	Registration process in the Mobility Region 11. Upon successful		Registration process in the Mobility Region 11. Upon successful
	registration MN communicates its IP address to the MSF in LER11 and		registration MN communicates its IP address to the MSF in LER11 and
	receives the related MSF information including the Region_ID=1.		receives the related MSF information including the Area_ID=1.
	(During the registration the newly initialized MN should use		(During the registration the newly initialized MN should use
	Region_ID=0).		Area_ID=0).
	2. LER11 creates a local Mobility Binding for the MN and updates		2. LER11 creates a Mobility Binding for the MN and updates AMRR1
	mRR1 using the Selective Mode specifying the MN's IP address, It's		using the Selective Mode and Internal Type, and specifying the MN's
	own Router_ID, the Mobility Label and the initial Region_ID=0. LER11		IP address, It's own Router_ID, the locally significant Mobility
	stores the received Mobility Binding and associates an empty LRL with		Label and the Area_ID=1. AMRR1 stores the received Mobility Binding
	it.		and associates an empty LRL with it.
	3. Assume that a Correspondent Node (CN) in the Mobility Region 34		3. Assume that a Correspondent Node (CN) in the Mobility Region 34
	sends a packet to the MN in the Mobility Region 11. The packet		sends a packet to the MN in the Mobility Region 11. The packet
	reaches LER34.		reaches LER34.
	4. LER34 identifies that the packet falls into the mobility address		4. LER34 identifies that the packet falls into the mobility address
	range and requests Mobility Binding information from its Regional		range and requests Mobility Binding information from its Area MRR3
	mRR3 using On-Demand Mobility Binding Request (see Figure 20). LER34		using On-Demand Mobility Binding Request (see Figure 20). LER34 uses
	uses the value of the Region_ID=3 in the request.		the value of the Area_ID=3 in the request.
	5. Since mRR3 does not have the Mobility Binding for the MN it		5. Since AMRR3 does not have the Mobility Binding for the MN it
	forwards the requests to both mRR1 and mRR2. mRR1 replies with the		forwards the requests to both AMRR1 and AMRR2. AMRR1 replies with
	Mobility Binding and mRR3 forwards the reply to LER34. Both mRR1 and		the Mobility Binding and AMRR3 forwards the reply to LER34. AMRR1
	mRR3 associate an LRL with the Mobility Binding listing the LER34		associates an LRL with the Mobility Binding listing the AMRR3's
	Router_ID and the Region_ID=3.		Router_ID and the Area_ID=3.
	6. LER34 forwards the packet to the MN using the LSP between LER11		6. LER34 forwards the packet to the MN using the LSP between LER11
	and LER34 and a stacked Mobility Label extracted from the received		and LER34 and a stacked Mobility Label extracted from the received
	Mobility Binding.		Mobility Binding. If the H-MLBN makes use of the Area LER nodes
			(thus also using the forwarding plane hierarchy) the Mobility Labels
			may include the ALER's Router_ID instead of the LER Router_ID. Thus
			the path between the LER nodes may consist of multiple segments (a
			segmented LSP): LER-ALER, ALER-ALER, ALER-LER.
	7. Assume that MN now moves into the Mobility Region 22. It		7. Assume that MN now moves into the Mobility Region 22. It
	initiates a new Discovery and Registration procedure and registers		initiates a new Discovery and Registration procedure and registers
	with the MSF at LER22 specifying its IP address and the Last		with the MSF at LER22 specifying its IP address and the Last
	Region_ID=1.		Area_ID=1.
	8. LER22 creates a local Mobility Binding for the MN and updates its		8. LER22 creates a local Mobility Binding for the MN and updates its
	regional mRR2 using Selective Mode and sending the Region_ID=1 along		regional AMRR2 using Selective Mode and Internal Type, and sending
	with the Mobility Binding.		the Area_ID=1 along with the Mobility Binding.
	9. mRR2 receives the new Mobility Binding and examines the associated		9. AMRR2 receives the new Mobility Binding and examines the
	value of Region_ID. If it is not equal to 0 then the LRL for this		associated value of Area_ID. If it is not equal to its own, then the
	binding must be requested from the mRR identified by the Region_ID.		LRL for this binding must be requested from the AMRR identified by
	In this case mRR2 sends the On-Demand request to mRR1 asking for the		the Area_ID. In this case AMRR2 sends the On-Demand request to AMRR1
	associated LRL created in step 5.		asking for the associated LRL created in step 5.
	10. mRR2 receives the LRL={Router_ID=LER34, Region_ID=3} from mRR1		10. AMRR2 receives the LRL={Router_ID=LER34, Region_ID=3} from AMRR1
	(see Figure 21) and sends a Mobility Binding update to mRR3 using the		(see Figure 21) and sends a Mobility Binding update to AMRR3 using
	Selective Downstream Push Mode with the "Target MP-BGP NEXT_HOP" set		the Selective Downstream Push Mode and the External Update Type and
	to the LER34 Router_ID.		with the "Target MP-BGP NEXT_HOP" set to the LER34 Router_ID.
	11. mRR3 receives the updated Mobility Binding and looks up the		11. AMRR3 receives the updated Mobility Binding and looks up the
	"Target MP-BGP NEXT_HOP". In this case it is equal to the LER34		"Target MP-BGP NEXT_HOP". In this case it is equal to the LER34
	Router_ID. mRR3 updates LER34 with the new Mobility Binding using		Router_ID. AMRR3 updates LER34 with the new Mobility Binding using
	Selective Downstream Push. LER34 starts to forward packets to the MN		Selective Mode and Internal Type. LER34 starts to forward packets to
	using the LSP between LER34 and LER22 (listed as the "Origin MP-BGP		the MN using the LSP between LER34 and LER22 (listed as the "Origin
	NEXT_HOP" in the updated Mobility Binding) and the new overlay		MP-BGP NEXT_HOP" in the updated Mobility Binding) and the new overlay
	Mobility Label.		Mobility Label.
	4.2. Hand-off Processing		4.2. Hand-off Processing
	The use of the Multi-Protocol BGP for mobility management allows a		The use of the Multi-Protocol BGP for mobility management allows a
	simple basic hand-off processing scheme to be implemented. In		simple basic hand-off processing scheme to be implemented. In
	particular, when a mobile node detects that it can no longer receive		particular, when a mobile node detects that it can no longer receive
	the keepalive acknowledgements from the serving MSF it initiates the		the keepalive acknowledgements from the serving MSF it initiates the
	new discovery and registration procedure. After the successful		new discovery and registration procedure. After the successful
	registration the new serving MSF will assign and distribute a new		registration the new serving MSF will assign and distribute a new
	skipping to change at page 53, line 5 ¶		skipping to change at page 54, line 5 ¶
	AFI=X2, SAFI=Y2 - MLBN Group Registration IPv6 Unicast		AFI=X2, SAFI=Y2 - MLBN Group Registration IPv6 Unicast
	AFI=X2, SAFI=Y3 - MLBN On-Demand Binding Information IPv6 Unicast		AFI=X2, SAFI=Y3 - MLBN On-Demand Binding Information IPv6 Unicast
	8. Acknowledgements		8. Acknowledgements
	The authors would like to thank Dr. Stuart Elby of Verizon		The authors would like to thank Dr. Stuart Elby of Verizon
	Communications for his insights and valuable suggestions related to		Communications for his insights and valuable suggestions related to
	this work.		this work.
	9. IPR Notice		9. Patent Issues
	The IETF has been notified of intellectual property rights claimed in		The IETF has been notified of intellectual property rights claimed in
	regard to some or all of the specification contained in this		regard to some or all of the specification contained in this
	document. For more information consult the online list of claimed		document. For more information consult the online list of claimed
	rights.		rights.
	10. References		The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
	10.1. Normative References		The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
			10. Changes from Previous Revisions
			00 -> 01
			- Replaced Region_ID with Area_ID in MSF Registration and Mobility
			Bindings
			- Replaced UT field in Mobility Binding with the UM field
			- Replaced the Resv. field in Mobility Binding with the UT field
			- Added Area_ID to the Mobility Binding Structure
			- Added sections 4.1.5, 4.1.5.1 and 4.1.5.2
			- Modified Section 4.1.7. Used H-MLBN instead of MILS
			- Added informative reference [MLBN]
			- Added Section 10
			11. References
			11.1. Normative References
	[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,		[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
	September 1991.		September 1991.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in		[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
	BGP-4", RFC 3107, May 2001.		BGP-4", RFC 3107, May 2001.
	skipping to change at page 54, line 36 ¶		skipping to change at page 56, line 36 ¶
	RFC 3963, January 2005.		RFC 3963, January 2005.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, February 2006.
	[RFC4443] Conta, A. and S. Deering, "Internet Control Message		[RFC4443] Conta, A. and S. Deering, "Internet Control Message
	Protocol (ICMPv6) for the Internet Protocol Version 6		Protocol (ICMPv6) for the Internet Protocol Version 6
	(IPv6) Specification", RFC 4443, March 2006.		(IPv6) Specification", RFC 4443, December 1998.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760,		"Multiprotocol Extensions for BGP-4", RFC 4760,
	January 2007.		January 2007.
	[RFC4861] Narten, T., Nordmark, E., and W. Simpson, "Neighbor		[RFC4861] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
	Discovery for IP Version 6 (IPv6)", RFC 4861,		Discovery for IP Version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and		[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
	B. Thomas, "LDP Specification", RFC 5036, October 2007.		B. Thomas, "LDP Specification", RFC 5036, January 2001.
	10.2. Informative References		11.2. Informative References
			[MLBN] Berzin, O., "Mobility Label Based Network: Mobility
			Support in Label Switched Networks with Multi-protocol
			BGP", Comput.-Netw. doi:10.1016/j.comnet.2008.03.001,
			2008.
	[MM-MPLS] Langar, L., Toshme, S., and N. Bouabdallah, "An Approach		[MM-MPLS] Langar, L., Toshme, S., and N. Bouabdallah, "An Approach
	for Mobility Modeling - Towards an Efficient Mobility		for Mobility Modeling - Towards an Efficient Mobility
	Management Support in Future Wireless Networks", IEEE/		Management Support in Future Wireless Networks", IEEE/
	IFIP NOMS, 2006.		IFIP NOMS, 2006.
	Authors' Addresses		Authors' Addresses
	Oleg Berzin		Oleg Berzin
	Verizon Communications		Verizon Communications
	skipping to change at page 57, line 7 ¶		skipping to change at page 59, line 7 ¶
	Verizon Communications		Verizon Communications
	40 Sylvan Road		40 Sylvan Road
	Waltham, MA 02451		Waltham, MA 02451
	US		US
	Phone: +1 781-466-2362		Phone: +1 781-466-2362
	Email: andrew.g.malis@verizon.com		Email: andrew.g.malis@verizon.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 106 change blocks.
	370 lines changed or deleted		460 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/