| Network Working Group | B. Sarikaya |
| Internet-Draft | |
| Intended status: Standards Track | L. Xue |
| Expires: May 3, 2018 | October 30, 2017 |
Distributed Mobility Management Protocol for WiFi Users in Fixed Network
draft-sarikaya-dmm-for-wifi-05.txt
As networks are moving towards flat architectures, a distributed approach is needed to mobility management. This document presents a use case distributed mobility management protocol called Distributed Mobility Management for Wi-Fi. The protocol is based on mobility aware virtualized routing system with software-defined network support. Routing is in Layer 2 in the access network and in Layer 3 in the core network. Smart phones access the network over IEEE 802.11 (Wi-Fi) interface and can move in home, hotspot and enterprise buildings.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Centralized mobility anchoring has several drawbacks such as single point of failure, routing in a non optimal route, overloading of the centralized data anchor point due to the data traffic increase, low scalability of the centralized route and context management [RFC7333].
In this document, we define a routing based distributed mobility management protocol. The protocol assumes a flat network architecture as shown in Figure 1. No client software is assumed at the mobile node.
IP level mobility signaling needs to be used even when MN is connected to a home network or a hotspot. Distributed anchors in the protocol are called Unified Gateways and they represent an evolution from the Broadband Network Gateway (BNG) currently in use.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This document uses the terminology defined in [I-D.ietf-dmm-deployment-models] and [I-D.matsushima-stateless-uplane-vepc].
This section presents an overview of the protocol, Distributed Mobility Management for Wi-Fi protocol (DMM4WiFi). See also Figure 1.
Access routers (AR) are Unified Gateways (UGW) that are the access network gateways that behave similarly as Evolved Packet Core (EPC) Edge Router (EPC-E) in [I-D.matsushima-stateless-uplane-vepc]. UGW is configured an anycast address on the interface facing the Residential Gateway (RG). RGs use this address to forward packets from the users. The fixed access network delivers the packets to geographically closest UGW. UGW plays the role of Access Data Plane Node (A-DPN) defined in [I-D.ietf-dmm-deployment-models]. A-DPN and UGW are interchangeably used in this document.
Cloud _.---------+----------.
,' ' ---''Virtualized Control Plane---'-.
( +---+ +---+ +---+ `.
`. |VM1| |VM2| |VM3| )
+---+ +---+ +--,+ ,'
IP Routers | _.---------+----------.
with SDN Clients ,----'' | `---'-.
and Agents ,-' | | \ `-.
,' | | ' `.
( | IP Network| \ )
`. | | ' ,'
`-. | ; ,\'
;-----. ---------+------------------
+-------+ +-------+ +-------+
| A-DPN | | A-DPN | | A-DPN |
+-------+ +-------+ +-------+
,' | `.
( Access Network )
`. | ,'
+-----+ +-----+ +-----+
| RG | | RG | | RG |
+-----+ +-----+ +-----+
+-----+ +-----+
| MN | ----move---------------> | MN |
+-----+ +-----+
Figure 1: SDN Based Architecture of Wi-Fi Protocol
Wi-Fi smart phone, the mobile node (MN) is assigned a unique prefix using either Stateless Address Auto Configuration (SLAAC) or by a DHCP server which could be placed in the cloud. In case of SLAAC, RG is delegated the prefixes by DHCP server using [RFC3633].
Prefix assignments to MNs are consistent with the prefixes assigned to UGWs that are shorter than /64. These prefixes are part of the operator's prefix(es) which could be /32, /24, etc.
The mobile node can move at home or in a hot spot from one Access Point (AP) to another AP and MN mobility will be handled in Layer 2 using IEEE 802.11k and 802.11r. Authentication is handled in Layer 2 using [IEEE-802.11i] and [IEEE-802.11-2007] (as described in Section 4.4).
When MN moves from one A-DPN into another A-DPN, IP mobility signaling needs to be introduced. In this document we use Handover Initiate/ Handover Acknowledge (HI/HAck) messages defined in [RFC5949]. Handover Initiate message can be initiated by either previous UGW (predictive handover) or the next UGW (reactive UGW). In reactive handover, RG establishes a new connection with the next UGW when MN moves to this RG and provides previous UGW address. This will trigger the next UGW to send HI message to the previous UGW. Previous UGW sends HAck messages which establishes a tunnel between previous and next UGWs. Previous UGW sends packets destined to MN to the new UGW which in turn sends them to MN.
Note that the mobility signaling just described is control plane functionality, i.e. between Access-Control Plane Nodes (A-CPN). Control plane in our document is moved to the cloud, thus mobility signaling happens at the cloud, possibly between two virtual machines (VM), A-CPNs.
Upstream packets from MN at the new A-DPN establish the initial routing path when MN first enters the system. This path needs to be updated as MN moves from one A-DPN to another, i.e. MN handover. Since MN keeps the prefix initially assigned, after handover, the new upstream path establishment may establish host routes in the upstream routers. This route is refreshed as long as MN stays under the same A-DPN. Handover signaling and subsequent upstream path establishment is very critical because the downstream packets may need to follow the path that is established for MN.
Software-Defined Networking (SDN) is used in DMM4WiFi in both Layer 2 and Layer 3 routing management. In case of Layer 2 routing, the Open Flow Switch Protocol is used as the south bound interface between the SDN Controller and Layer 2 access network switches. Extensible Messaging and Presence Protocol (XMPP) is used as the north bound interface between the SDN controller and DMM4WiFi application. DMM4WiFi Layer 3 routing is based on SDN controllers manipulating Routing Information Bases (RIB) in a subset of the upstream routers. In this case south bound interface is the NETCONF protocol which is based on the Remote Procedure Call (RPC) protocol and YANG. I2RS architecture is used in this context.
Mobile node generates interface identifier using [RFC7217] in SLAAC. With this method, MN interface identifiers will be different when MN moves from one A-DPN to another A-DPN. MN MAY have different IPv6 addresses due to this method of interface identifier generation.
In this section, Layer 2 and Layer 3 mobility procedures are explained.
In the access network, RG MAC address acts as an identifier for the MN. Access network switches are controlled by SDN. Controller to Switch interface uses a protocol such as Extensible Messaging and Presence Protocol (XMPP) [RFC6121]. XMPP is based on a general subscribe-publish message bus. SDN controller publishes forwarding instructions to the subscribing switch. Forwarding instructions could be Open Flow like match-forward instructions. Open Flow protocol can also be used [ONFv1.5].
Access network is organized as interconnected switches. The switch connected to the RG is called egress switch. The switch connected to the UGW is called ingress switch. IEEE 802.1ad standard for VLAN (Q- in-Q) is used in the access network, where S-VLAN denotes RG groups, and C-VLAN determines traffic classes. One S-VLAN tag is assigned to create one or more VLAN paths between egress and ingress switches.
MN mobility in the access network can be tracked by keeping a table consisting of MN IP address and RG MAC address pairs. In this document SDN controllers keep the mobility table. This table is used to select proper S-VLAN downstream path from ingress switch to egress switch and upstream path from egress switch to ingress switch.
After a new MN with WiFi associates with RG, RG sends an Unsolicited Neighbor Advertisement (NA) message upstream. This NA message is constructed as per [RFC4861] but the Source Address field is set to a unicast address of MN. NA message is received by SDN controller and it enables SDN controller to update the mobility table. SDN controller selects proper path including S-VLAN and ingress switch to forward the traffic from this MN. The controller establishes the forwarding needed on these switches [IEEE-Paper], i.e. Layer 2 route.
The packet eventually reaches the closest UGW due to the anycast addressing used at the access network interfaces. UGW forwards this packet to the upstream router and so on. The upstream router establishes a route for MN in its routing table with MN's prefix and with the UGW as the next hop. Prefixes in those routes get smaller and smaller as the packet moves upstream in the routing hierarchy. The routing protocol used could be BGP or other protocols like IS-IS.
MN moving from one RG to another may eventually require MN moving from one A-DPN to another. This is Layer 3 mobility.
Predictive handover happens when MN just before leaving the previous RG (pRG) for the next RG (nRG) MN is able to send an 802.11 message containing MN MAC address and nRG MAC address, e.g. learned from beacons to the pRG (called Leave Report in Figure 2. pRG then sends a handover indication message to pUGW providing MN and nRG addresses (called Leave Indication) and this could happen between two respective virtual machines in the cloud. This message results in pUGW getting nUGW information and then sending Handover Initiate message to nUGW, which also could happen in the cloud. nUGW replies with Handover Acknowledge message. pUGW sends any packets destined to MN to nUGW after being alerted by the control plane. MN moves to nRG and nUGW is informed about this from Layer 2 mobility Section 4.1. uGW delivers MN's outstanding packets to MN.
MN P-RG N-RG (P-UGW) (N-UGW) Cloud
| Leave | | | | |
(a) |--Report-->| | | | |
| | | | | |
| | Leave | | |
(b) | |------indication------>| | |
| | | | | |
| | | | | |
(c) | | | |----HI---->| |
| | | | | |
| | | | | |
(d) | | | |<---HAck---| |
| | | |===========| |
Figure 2: Predictive Handover
Reactive handover handover happens when MN attaches the new RG from the previous RG, called Join Report in Figure 3. MN is able to signal in 802.11 association messages previous RG MAC address. nUGW or A-CPN receives new association information together with pRG information, possibly in the cloud (called Handover Indication). nUGW finds pUGW address and sends HI message to pUGW, again happening between two virtual machines in the cloud. pUGW after receiving indication from the cloud server delivers any outstanding MN's packets to nUGW which in turn delivers them to MN.
MN P-RG N-RG (P-UGW) (N-UGW) Cloud
| Join | | | | |
(a) |--Report------------->| | | |
| | | Handover | |
(b) | | |------Indication------->| |
| | | | | |
(c) | | | |<----HI----| |
| | | | | |
(d) | | | |----HAck-->| |
| | | | | |
(e) | | | |<--------->| |
| | | | | data |
(f) | | | |===========| |
Figure 3: Reactive Handover
Note that Handover Initiate and Handover Acknowledge messages used in this document carry only a subset of parameters defined in [RFC5949]. Also no involvement with the Local Mobility Anchor (LMA) [RFC5213] is needed.
After handover, SDN route establishment in upstream routers needs to take place. In this case NETCONF protocol [RFC6241] and YANG modeling [RFC6020] are used.
Client and Server exchange their capabilities using NETCONF message layer message called hello messages. Client builds and sends an operation defined in YANG module, encoded in XML, within RPC request message [RFC6244]. Server verifies the contents of the request against the YANG module and then performs the requested operation and then sends a response, encoded in XML, in RPC reply message.
Defining configuration data is the primary focus of YANG. Configuration data is writable (rw - read-write) data that is required to transform a system from its initial default state into its current state. There is also state data (ro - read-only) which is a set of data that has been obtained by the system at runtime. An example is routing table changes made by routing protocols in response to the ongoing traffic.
A YANG module for routing management is given in [I-D.ietf-netmod-routing-cfg]. The core routing data model consists of three YANG modules, ietf-routing, ietf-ipv4-unicast-routing, ietf- ipv6-unicast-routing. The core routing data model has two trees: configuration data and state data trees. "routing-instance" or "rib" trees have to be populated with at least one entry in the device, and additional entries may be configured by a client. Normally the server creates the required item as an entry in state data. Additional entries may be created in the configuration by a client via the NETCONF protocol using RPC messages like edit-config and copy-config.
The user may provide supplemental configuration of system- controlled entries by creating new entries in the configuration with the desired contents. In order to bind these entries with the corresponding entry in the state data list, the key of the configuration entry has to be set to the same value as the key of the state entry.
RPC get message can be used to retrieve all or part of the running configuration data store merged with the device's state data. RPC get-config operation retrieves configuration data only. RPC fib- route message defined in [RFC8022] retrieves a routing instance for the active route in the Forwarding Information Base (FIB) which is the route that is currently used for sending datagrams to a destination host whose address is passed as an input parameter. So fib-route message plays the role of show route command line interface command.
NETCONF protocol and ietf-routing YANG module can be used for route establishment after handover. As a result for MNs that handover, upstream routing that takes place is not modified up to the lowest level of routers. The lowest level of routers handle the mobility but only proper modifications are needed so that the packets reach the right Unified Gateway, i.e. nUGW.
I2RS Agent as NETCONF Server in nUGW and in pUGW inform the handover to I2RS Clients as NETCONF Client upstream. I2RS Agent at pUGW removes any routing information for MN by first using get-config to retrieve the active route for MN and then an edit-config message with delete operation to delete the active route making sure that the same key is used.
I2RS Agent in nUGW after the handover needs to add a new routing table entry for MN. Due to the topological correctness of MN's prefix, the new route could be a host route. Next this route is propagated upstream. In this case, nUGW starts the process. SDN Controller as I2RS Client knows that MN handover is successfully completed. SDN Controller starts the upstream route establishment process starting with the I2RS Agent at the upstream router. Either a new route or the host route is added with shorter prefix. Route propagation continues until MN's prefix becomes topologically correct at which point route propagation stops.
Route propagation at the lowest level starts with I2RS Agent as NETCONF Server in nUGW informing the handover to I2RS Client as NETCONF Client upstream. I2RS Client then checks any routing information for MN by first using get-config to retrieve the active route for MN to make sure that none exits and MN prefix is topologically incorrect. Next I2RS client issues an edit-config message with create operation to add a host route for the new MN. I2RS Client then informs this route to I2RS Client upstream which creates a similar route at the I2RS Agent upstream.
In Appendix A, we present our experimental work using YANG data modelling language which has its own syntax and NETCONF protocol which is XML-based remote procedure call (RPC) mechanism. HTTP based RESTCONF could also be used in a similar way. Two RPC call examples are given. RPC call in Appendix A.3 shows a get-config filter with rtr0 as the key and it is used to retrieve a specific route with a given destination prefix and next hop address. RPC call in Appendix A.4 shows an example edit-config create operation to create a new route with specific route parameters.
Extensible Authentication Protocol (EAP)[RFC3748] is preferred for MN authentication in IEEE 802.11 (Wi-Fi) network. When a MN tries to connect to the WiFi, it needs to mutually authenticate with the network server first. A successful EAP authentication procedure must result in a Pairwise Master Key(PMK) (defined in [IEEE-802.11i]) for the traffic encryption between the MN and the AR.
When a MN moves at home or in a hot spot from one AP to another AP in the same UGW, it is possible that it may to undergo a full EAP authentication (as defined in[RFC3748]). However, there are several simplified authentication methods (defined in [IEEE-802.11-2007] ):
o Preauthentication: When The MN supplicant may authenticate with both pRG and nRG at a time. Successful completion of EAP authentication between the MN and nRG establishes a pair of PMKSA on both the MN and nRG. When the MN moves to the nRG, the authentication has already done, which is shown as follows.
+---------------+
| Authentication|
| Server |
+--*----*-------+
Preauthentication <..........*
/ *
+---------*-----+
|/ *UGW |
*---------*-----+
,' / * | `.
( / Access *Network )
`. / * | ,'
+-----* +-*---+ +-----+
| RG /| ******* RG | | RG |
+----/+ ***** +-----+ +-----+
+-----**** +-----+
| MN | ----move-----> | MN |
+-----+ +-----+
o Cached PMK: The RG reserves the PMK as a result of previous authentication. When the MN is roaming back to the previous RG, if a successful EAP authentication has happened. The MN can retain the 802.11 connection based on PMK information reserved. When the authentication is handled by the UGW as an Authenticator. When the MN moves to the nRG, a join report packet will be initiated from the MN to nRG for IEEE802.11 connection to the same UGW. The nRG can retain the PMK information from the UGW which is reserved during the successful authentication procedure between the MN and the pRG, as shown in Figure 4.
+---------------+
| Authentication|
| Server |
+--*------------+
Authentication <....*
/
*-------------+
/| UGW | PMK Cache
/ +-------------+ /
,' / | / `.
( / Access Network/ )
`. / | / ,'
+-----* +-----+</ +-----+
| RG /| | RG | | RG |
+----/+ +-----+ +-----+
+----- +-----+
| MN | ----move-----> | MN |
+-----+ +-----+
Figure 4: Cached PMK-UGW Authenticator
When a MN moves at home or in a hot spot from one AP to another AP in the same UGW, it is possible that it may to undergo a full EAP authentication (as defined in[RFC3748]). However, there are several simple authentication methods (defined in [IEEE-802.11-2007] ):
When MN moves from one UGW into another UGW, a join report packet will be initiated from the MN to nRG for IEEE802.11 connection. It is possible that it may to undergo a full EAP authentication (as defined in[RFC3748]). However, because of service performance and continuity requirement, the operators prefer to avoid the full EAP authentication. There are several simplied authentication methods (defined in [IEEE-802.11-2007] ):
o Preauthentication: MN supplicant may authenticate with both pRG and nRG at a time. Successful completion of EAP authentication between the MN and nRG establishes a pair of PMKSA on both the MN and nRG. When the MN moves to the nRG, the authentication has already been completed, which is shown as follows.
+---------------+
| Authentication|
| Server |
+--*----*-------+
Preauthentication <..........*
/ *
+-------+ / +-*-----+ +-------+
| UGW | / | *UGW | | UGW |
+-------+ / +-*-----+ +-------+
,' / * | `.
( / Access *Network )
`. / * | ,'
+-----* +-*---+ +-----+
| RG /| ******* RG | | RG |
+----/+ ***** +-----+ +-----+
+-----**** +-----+
| MN | ----move-----> | MN |
+-----+ +-----+
o Cached PMK: The RG reserves the PMK as a result of previous authentication. When the MN is roaming back to the previous RG, if a successful EAP authentication has happened. The MN can retain the 802.11 connection based on PMK information reserved. When the authentication is handled by the UGW as an Authenticator. When the MN moves to the nRG, a join report packet will be initiated from the MN to nRG for IEEE802.11 connection to nUGW. The nRG can retain the PMK information from the nUGW, the nUGW may can retain the reserved PMK from the pUGW based on HI message.
+---------------+
| Authentication|
| Server |
+--*------------+
Authentication <..../
/
+---------+ HI(PMK Q)+---------+
PMK Cached| pUGW |<-------- | nUGW |
++--------+ -------> +--------++ ^ Join Report Msg
,' | / HAck(PMK) | | `.
( | / | | )
`. | / Access Network | | ,'
+----+* +-----+ ++--+-+
| RG /| | RG | | RG |
+----/+ +-----+ +-----+
+----- +-----+
| MN | ----move--------------- | MN |
+-----+ +-----+
The above Layer 2 operations do not affect Layer 3. MN does not change the prefix assigned to it initially.
Note that charging solution is not described in this version.
Multicast communication to the mobile nodes can be supported with an Multicast Listener Discovery (MLD) Proxy at the Unified Gateway [RFC4605]. Downstream protocol operations between the UGW and the mobile nodes, is the MLD protocol [RFC3810]. Both any source and source specific multicast are supported.
The mobile nodes send MLD Report message when joining a multicast group [RFC3590]. UGW or MLD Proxy sends an aggregated join message upstream. MN and UGW interface works as described in [RFC6224]. After MN joins the group it starts to receive multicast data.
After a handover the mobile node moves to the next UGW, the next UGW needs to get membership or listening state of this MN containing group address and source list. For this purpose, Active Multicast Subscription mobility option (Type 57 for IPv6) [RFC7161] can be used to transfer mobile node's multicast context or subscription information from the previous UGW to the next UGW, as explained below.
In case of predictive handover, pUGW and nUGW follow the sequence of steps shown in Figure 2. In case MN has multicast context established before handover pUGW MUST transfer MN's multicast context to nUGW. pUGW MUST add Active Multicast Subscription mobility option to HI message.
For reactive handover pUGW and nUGW follow the sequence of steps shown in Figure 3. In case MN has multicast context established before handover pUGW MUST transfer MN's multicast context to nUGW. pUGW MUST add Active Multicast Subscription mobility option to HAck messeage.
After receiving the multicast context, nUGW upstream joins any new multicast groups on behalf of MN. Downstream, nUGW maps downstream point-to-point link to a proxy instance.
IPv4 can be supported similarly as in vEPC [I-D.matsushima-stateless-uplane-vepc]. UGW stays as IPv6 node receiving from all RGs IPv6 packets and forwarding them upstream.
IPv4 MN is supported at the RG. RG has B4 functionality of DS-Lite [RFC6333], CLAT entity for 464XLAT [RFC6877], Lightweight B4 [RFC7596] or MAP Customer Edge [RFC7597]. RG encapsulates IPv4 packets using these protocols into IPv6 packets making sure that UGW stays IPv6 only.
TBD.
This document introduces no extra new security threat. Security considerations stated in [RFC7921] and [I-D.ietf-dmm-deployment-models] apply.
We would like to thank Ladislav Lhotka, Satoru Matsushima for valuable advice.
| [I-D.matsushima-stateless-uplane-vepc] | Matsushima, S. and R. Wakikawa, "Stateless user-plane architecture for virtualized EPC (vEPC)", Internet-Draft draft-matsushima-stateless-uplane-vepc-06, March 2016. |
| [IEEE-Paper] | "Jyotirmoy Banik, et al., "IEEE 24th International Conference on Computer Communication and Network 2015, "Enabling Distributed Mobility Management: A Unified Wireless Network Architecture Based on Virtualized Core Network", DOI: 10.1109/ICCCN.2015.7288404",", August 2015. |
| [RFC7333] | Chan, H., Liu, D., Seite, P., Yokota, H. and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014. |
| [RFC7921] | Atlas, A., Halpern, J., Hares, S., Ward, D. and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016. |
In this annex, we present our YANG and RPC solutions.
We first obtained host routing YANG module using IPv6 unicast routing module (ietf-ipv6-unicast-routing) which is part of ietf-routing module. This module defines a list of host routes which contain host address/prefix and corresponding next hop address.
This program runs on ietf-ipv6-unicast-host-routing YANG module which has been obtained from ietf-ipv6-unicast-routing module by defining the hostroute as a list of host routes. First issue a get-config on the configuration data to extract the existing route for the host whose prefix is destination-prefix and the next-hop is the next-hop address. Delete the route at pUGW. This procedure deletes the route at pUGW.
<rpc message-id="101" ... >
get-config(running, filter=(destination-prefix, next-hop-address))
// check the reply, make sure it is OK, i.e. does not contain <rpc-
error> element.
edit-config(running, delete, config)
Add a new route for MN at nUGW. This route is based on MN's prefix,
destination-prefix and the upstream router to which MN's traffic
should routed, next-hop-address.
<rpc message-id="101" ... >
get-config(running, filter=(destination-prefix, next-hop-address))
// check the reply, make sure it is an error, i.e. it contains <rpc-
error> element of type application and tag data-missing i.e. no route
exists
edit-config(running, create, config)
Add a new host route for MN at nUGW. This route is added in case
MN's prefix is not topologically correct at nUGW and routers above.
<rpc message-id="101" ... >
get-config(running, filter=(destination-prefix, next-hop-address))
// check the reply, make sure it is an error, i.e. it contains <rpc-
error> element of type application and tag data-missing, i.e. no
route exists
edit-config(running, create, config)
We next show in Appendix A.3 and Appendix A.4 example RPC procedures for get-config and edit-config. Some arbitrary values for destination prefix and next hop address are used.
This RPC procedure shows a get-config filter to find a record in the routing information base for a specific host whose prefix is 2001:db8:1:0::/64 and the next-hop is 2001:db8:0:1::2. It could be used for the get-config's in Appendix A.2. We validated this procedure using the public domain tool pyang.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip"
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<t:top xmlns:t="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-host-routing">
<t:routing-instance> rtr0 </t:routing-instance>
<t:rib>
<t:routes>
<t:route>
<t:destination-prefix>
2001:db8:1:0::/64
</t:destination-prefix>
<t:outgoing-interface>eth1</t:outgoing-interface>
<t:next-hop-address>
2001:db8:0:1::2
</t:next-hop-address>
</t:route>
</t:routes>
</t:rib>
</t:top>
</filter>
</get-config>
</rpc>
This RPC procedure shows an edit-config procedure to create a new host route in the routing information base for a specific host whose prefix is 2001:db8:1:0::/64 and the next-hop is 2001:db8:0:1::2. It could be used for the edit-config's in Appendix A.2. We validated this procedure using the public domain tool pyang.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:v6ur="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip"
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing">
<edit-config>
<target>
<running/>
</target>
<default-operation>none</default-operation>
<config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-host-routing">
<routing-instance> rtr0 </routing-instance>
<rib>
<routes>
<route xc:operation="create">
<destination-prefix >
2001:db8:1:0::/64
</destination-prefix>
<outgoing-interface>eth1</outgoing-interface>
<next-hop-address>
2001:db8:0:1::2
</next-hop-address>
</route>
</routes>
</rib>
</top>
</config>
</edit-config>
</rpc>