Oh I’ve just noticed that you are referring -02 version. But the latest version is -03. Please find it from following link:
https://tools.ietf.org/html/draft-matsushima-spring-dmm-srv6-mobile-uplane-03 You can find much more about how stateless interworking works and its benefits. Control-plane consideration has also been described well than -02 version. Cheers, --satoru > 2017/11/13 20:14、Satoru Matsushima <satoru.matsush...@gmail.com>のメール: > > Thank you Sri, for your review. > >> 1.) It will be useful to identify the key data plane features used today in >> conjunction with the tunnel based approach and how those features are >> impacted when using SRv6 user plane. > > Sure. But I’d just cite existing document which well described current > approach. It would be sfc for mobile document as one of them: > > https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility > > But I couldn’t find tunneled path optimization and service chaining. So it > seems to be explained in our I-D, do you think so? > > >> 2.) There are heartbeat protocols that is used for path check between the >> access and anchor. > > Ok, that would be an OAM feature like ICMPv6 in SRv6. Will try to mention it. > > >> Assuming those mechanisms are still in use between the access and anchor, I >> am wondering how these failure events impact the SRv6 states? For exam >> 3.) Discussion on definition of new SRv6 functions needed to support this >> architecture will help > > Right. Those are End.TM and T.Tmap introduced for stateless interworking > between existing user-plane and SRv6 user-plane. Why “statless” is that not > to affect existing c-plane and to avoid more mobile state aware entities > because one of DMM purposes is to get rid out of mobile state from DPNs as I > understand. > > >> 4.) It will be good if this document sets the overall context, allowing >> additional drafts to focus on specific aspects. > > Yes, while the revise work I found that at least IPv4 support would be good > to explain in an additional draft. But in terms of overall context, it would > be nice if we can have another document to explain that overall context in > addition to this draft because it mentions specific solution already. I think > I can help to work on that generic document in case some volunteers we can > involve. > > I’ll get back to following your comments on specific part of the draft. > > Cheers, > --satoru > > > >> >> Please see inline for additional comments. >> >> --------------------------------------------------------- >> Segment Routing IPv6 for Mobile User-Plane >> draft-matsushima-spring-dmm-srv6-mobile-uplane-02 >> >> Abstract >> >> This document discusses the applicability of SRv6 (Segment Routing >> IPv6) to user-plane of mobile networks that SRv6 source routing >> capability with its programmability can fulfill the user-plane >> functions, such as access and anchor functions. It takes advantage >> of underlying layer awareness and flexibility to deploy user-plane >> functions that enables optimizing data-path for applications. >> Network slicing and an interworking way between SRv6 and existing >> mobile user-plane are also discussed in this document. >> >> Status of This Memo >> >> 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 http://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 Notice >> >> 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 >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 1] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> (http://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. >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 >> 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 >> 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 4. Mobile User-Plane . . . . . . . . . . . . . . . . . . . . . . 3 >> 5. Segment Routing IPv6 for Mobile User-Plane Functions . . . . 5 >> 6. SRv6 Functions and Behaviors for User-Plane . . . . . . . . . 6 >> 6.1. Per Session Segment for Basic User-Plane . . . . . . . . 6 >> 6.1.1. Uplink . . . . . . . . . . . . . . . . . . . . . . . 6 >> 6.1.2. Downlink . . . . . . . . . . . . . . . . . . . . . . 7 >> 6.2. Aggregated Segment for Basic User-Plane . . . . . . . . . 8 >> 6.2.1. Uplink . . . . . . . . . . . . . . . . . . . . . . . 8 >> 6.2.2. Downlink . . . . . . . . . . . . . . . . . . . . . . 8 >> 6.3. Stateless Interworking . . . . . . . . . . . . . . . . . 9 >> 6.4. Rate Limit Function . . . . . . . . . . . . . . . . . . . 10 >> 7. Network Slicing Considerations . . . . . . . . . . . . . . . 11 >> 8. Control Plane Considerations . . . . . . . . . . . . . . . . 11 >> 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 >> 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 >> 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 >> 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 >> 11.2. Informative References . . . . . . . . . . . . . . . . . 12 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 >> >> 1. Introduction >> >> In mobile networks, mobility management systems provide connectivity >> while mobile nodes move around. While the control-plane of the >> system signals movements of a mobile node, user-plane establishes >> tunnel between the mobile node and anchor node over IP based backhaul >> and core networks. >> >> This document discusses the applicability of SRv6 (Segment Routing >> IPv6) to those mobile networks. SRv6 provides source routing to >> networks where operators can explicitly indicate route for the >> packets from and to the mobile node. SRv6 endpoint nodes act as >> roles of anchor of mobile user-plane. >> >> >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 2] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> 2. Conventions and Terminology >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119]. >> >> All segment routing and SRv6 network programming terms are defined in >> [I-D.ietf-spring-segment-routing] and >> "[I-D.filsfils-spring-srv6-network-programming]. >> >> 3. Motivations >> >> Today's and future applications are requiring highly optimized data- >> path between mobile nodes and the entities of those applications in >> perspectives of latency, bandwidth, etc,. However current >> architecture of mobile management is agnostic about underlying >> topologies of transport layer. It rigidly fragments the user-plane >> in radio access, core and service networks and connects them by >> tunneling techniques through the user-plane functions such as access >> and anchor nodes. Those agnostic and rigidness make it difficult for >> the operator to optimize the data-path. >> >> While the mobile network industry has been trying to solve that, >> applications shift to use IPv6 data-path and network operators adopt >> it as their IP transport as well. >> SRv6 integrates both application >> data-path and underlying transport layer in data-path optimization >> aspects that does not require any other techniques. >> >> >> [Sri] May be worth rephrasing with more details. >> >> SRv6 source routing capability with programmable functions >> [I-D.filsfils-spring-srv6-network-programming] could fulfills the >> user-plane functions of mobility management. It takes advantage of >> underlying layer awareness and flexibility to deploy user-plane >> functions. Those are the motivations to adopt SRv6 for mobile user- >> plane. >> >> 4. Mobile User-Plane >> >> This section describes user-plane using SRv6 for mobile networks. >> This clarifies mobile user-plane functions to which SRv6 endpoint >> applied. >> >> Figure 1 shows mobile user-plane functions which are connected >> through IPv6-only networks. In the Figure 1, an mobile node (MN) >> connects to an SRv6 endpoint serving access point role for the MN. >> When the endpoint receives packets from the MN, it pushes SRH to the >> packets. The segment list in the SRH indicates the rest of user- >> plane segments which are L2 and L3 anchors respectively. Then the >> endpoint send the packets to the IPv6 network. In opposite >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 3] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> direction, when an SRv6 endpoint serving L3 anchor role for the MN >> receives packets to it, the endpoint push SRH consist of the L2 >> anchor and access point segments to the packets. >> >> [Sri] I realize the control-plane extensions are outside the scope of this >> work, but might be worth explaining how the CP influences the segment list >> generation at the endpoint. I am assuming the User Plan Anchor selection, >> the IP address allocation would influence this segment list selection. May >> be you want to cover this in Appendix section for PMIP-based and GTP-based >> control plane as examples. >> >> >> >> User-plane >> Function >> <L2 Anchor> >> O------O >> | SRv6 | >> | End | >> | Point| >> O------O >> User-plane || User-plane >> [MN] Function _____||_____ Function >> | <Access Point> / \ <L3 Anchor> >> ___v___ O------O / \ O------O ________ >> / Radio \ | SRv6 | / \ | SRv6 | / \ >> / Access \==| End |===/ IPv6-Only \===| End |===/ Service \ >> \ NW / | Point| \ Network / | Point| \ NW / >> \________/ O------O \ / O------O \________/ >> \ / >> \____________/ >> >> >> Figure 1: Mobile User-plane with SRv6 >> >> An SRv6 segment represents those each function, such as Access Point, >> Layer-2 (L2) Anchor and Layer-3 (L3) Anchor. This makes mobile >> networks highly flexible to deploy any user-plane functions to which >> nodes in user flow basis. >> An SRv6 segment can represent a set of >> flows in any granularity of aggregation even though it is just for a >> single flow. >> >> [Sri] May be some more explanation will greatly help >> >> Figure 2 shows that an SRv6 endpoint connects existing IPv4 mobile >> user-plane, which is defined in [RFC5213] and [TS.29281]. An SRv6 >> segment in the endpoint represents interworking function which >> enables interworking between existing access point and SRv6 anchor >> segment, or SRv6 access point segment and existing anchor node. >> >> Existing mobile user-plane with IPv6 underlay is expected to be >> widely deployed. As IPv6 network should be interoperable with SRv6 >> endpoints can be accommodated on it, interworking with existing IPv6 >> network is out of scope of this document. >> >> >> >> >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 4] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> ________ _______ >> / \ O------O / \ >> / Service \===|L2/L3 | / Service \ >> \ NW / |Anchor| User-plane \ NW / >> \________/ |Node | Function \_______/ >> O------O <Interworking> || >> \\_______ O------O ________ O------O >> / \ | SRv6 | / \ | SRv6 | >> / Existing \===| End |===/ IPv6-Only\===| End | >> \ IPv4 NW / | Point| \ Network / | Point| >> [MN] \________/ O------O \________/ O------O >> | // || >> ___v____ O------O ___||__ >> / Radio \ |Access| / Radio \ >> / Access \==|Point | [MN]~~~/ Access \ >> \ NW / |Node | \ NW / >> \________/ O------O \________/ >> >> >> >> >> >> Figure 2: Interworking with Existing Mobile Networks >> >> The detail of SRv6 segments representing user-plane functions are >> described in Section 5. >> >> 5. Segment Routing IPv6 for Mobile User-Plane Functions >> >> This section describes mobile user-plane functions to which SRv6 node >> can apply SRv6 functions and behaviors so that the nodes configured >> those segments can fulfills the user-plane functions. Each function >> consist of two segments which are uplink (UL) from mobile node to the >> correspondent node, and downlink (DL) from the correspondent node to >> mobile node. >> >> We support following mobile user-plane functions: >> >> Access Point: >> >> Access Point function provides SRv6 node the role to which >> mobile node is connected directly. eNodeB could be referenced >> as an entity implementing the access point in 3GPP term. >> >> >> [Sri] Should the AP/eNB be impacted for supporting this architecture? Even >> though the air interface terminates on the AP, for all practical purposes >> the first-hop router has all the L2 awareness. Unless there is a need to >> look at the radio parameters/state (Ex: RSSI values ..etc) and if that can >> impact the SRv6 state machine on the endpoint, I wonder why the AP/eNB >> should have any SRv6 awareness. Or, may I am missing the point around "SRv6 >> node the role to which mobile node is connected directly.”. >> Layer-2 Anchor: >> >> Layer-2 anchor function provides SRv6 node the role to be >> anchor point while mobile node move around within a serving >> area which could be assumed as a layer-2 network. Serving >> Gateway (SGW) could be referenced as an entity implementing the >> layer-2 anchor in 3GPP term. >> >> >> [Sri] Does micro-mobility (UE movement within the radio network) under the >> same L2 anchor has any implication on the SRv6 operation ? Can a L2 handoff >> trigger some change in SRv6 state machine? >> The key question in my above two comments is where does SRv6 begin, at AP or >> at First-hope router? >> Layer-3 Anchor: >> >> Layer-3 anchor function provides SRv6 node the role to be >> anchor point across a mobile network consists of multiple >> serving areas. Packet data network gateway (PGW) could be >> referenced as an entity implementing the layer-3 anchor. >> >> >> >> Stateless Interworking: >> >> Stateless interworking function provides SRv6 node the role to >> interworking between existing mobile user-plane and SRv6 mobile >> user-plane. It is expected that the endpoint of interworking >> segment could be unaware from the control-plane of the mobility >> management. While there are combinations of interworking >> either existing or SRv6 network in which user-plane functions >> accommodate, interworking segment should cover all combinations >> without mobility state. >> >> 6. SRv6 Functions and Behaviors for User-Plane >> >> This section describes SRv6 functions and behavior applied to mobile >> user-plane roles by use cases. Terminology of SRv6 endpoint >> functions refers to [I-D.filsfils-spring-srv6-network-programming]. >> In addition to that, new SRv6 functions and behaviors are introduced >> to cover some user cases. >> >> 6.1. Per Session Segment for Basic User-Plane >> >> In this use case, we assume that mobile user-plane consists of SRv6 >> segments per session basis. We expect the user-plane functions as >> same as existing ones except using SRv6. That means it just provides >> fundamental IPv6 connectivity for MNs and no advanced segment routing >> features introduced to it. >> >> >> [Sri] What does per-session mean here? A mobile subscriber session with a >> specific IP address which is anchored on a UP Anchor? >> Will all IP flows (Ex: TCP/UDP) for a given subscriber and with a specific >> source IPv6 address, always have the anchor (L3 endpoint)? >> >> 6.1.1. Uplink >> >> In uplink, SRv6 node applies following SRv6 end point functions and >> transit behavior. >> >> Access Point: T.Insert >> >> L2-Anchor: End.B6 >> >> L3-Anchor: End.T >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 6] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> When the access point node receives a packet destine to "D::1" from a >> mobile node "S::1", it does T.Insert process for the receiving >> packets to push a SRH with SID list (A2::1, D::1) and sets SL=1. The >> access point node update DA to "A2::1" which indicates the UL >> L2-Anchor SID and forward the packet. >> >> >> [Sri] Its good explain the above without impacting the AP. >> The L2-anchor node of "A2::1" segment does End.B6 process for the >> receiving packet according to the segment. The node updates DA to >> next UL L3-anchor segment "A3::1" associated with "A2::1". In this >> basic use case, just one UL L3-anchor SID with SL=0 is enough to do >> it so that there is no need to push another SRH to the packet in that >> PSP (Penultimate Segment Pop) operation. >> >> The L3-anchor node of "A3::1" segment does End.T process for the >> receiving packet according to the SRH that the node updates DA to >> D::1, decrement SL and lookup IPv6 table associated with "A3::1". In >> this basic use case, decremented SL is 0 so that the node does PSP >> operation of popped out the SRH from the packet and forward it. >> >> 6.1.2. Downlink >> >> In downlink, SRv6 node applies following SRv6 end point functions and >> transit behavior. >> >> L3-Anchor: T.Insert >> >> L2-Anchor: End.B6 >> >> Access Point: End.X >> >> When the L3-anchor node receives a packet destine to "S::1" from a >> correspondant node "D::1", it does T.Insert process for the receiving >> packets to push a SRH with SID list (A2::2, S::1) and sets SL=1. The >> access point node update DA to "A2::2" which indicates the DL >> L2-Anchor SID and forward the packet. >> >> The L2-anchor node of "A2::2" segment does End.B6 process for the >> receiving packet according to the segment. The node updates DA to >> next DL access point segment "A1::2" associated with "A2::2". In >> this basic use case, just one DL access point SID with SL=0 is enough >> to do it so that there is no need to push another SRH to the packet >> in that PSP (Penultimate Segment Pop) operation. >> >> The access point node of "A1::2" segment does End.X process for the >> receiving packet according to the SRH that the node updates DA to >> S::1, decrement SL and forward the packet to the mobile node through >> its associated radio channel. In this basic use case, decremented SL >> >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 7] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> is 0 so that the node does PSP operation of popped out the SRH from >> the packet and forward it. >> >> 6.2. Aggregated Segment for Basic User-Plane >> >> We assume that basic user-plane as well as Section 6.1 here, however >> this section describes that SRv6 nodes allocate an aggregated segment >> for multiple sessions, not in per session basis. Thank to IPv6 GUA, >> there is no need to employ additional identifier to distinguish each >> session. This benefits SRv6 node allows to apply one segment to >> mobile sessions which belong to same policy. >> >> >> [Sri] Some explanations on the assumption around “session" definition will >> help >> 6.2.1. Uplink >> >> In uplink, SRv6 node applies following SRv6 end point functions and >> transit behavior. >> >> Access Point: T.Insert >> >> L2-Anchor: End.B6 >> >> L3-Anchor: End.T >> >> When the access point node receives a packet destine to "D::1" from a >> mobile node "S::1", it does T.Insert process for the receiving >> packets to push a SRH with SID list (AG20::, D::1) and sets SL=1. >> The access point node update DA to "AG20::" which indicates >> aggregated UL L2-Anchor SID and forward the packet. >> >> The aggregated L2-anchor node of "AG20::" segment does End.B6 process >> for the receiving packet according to the segment. The node updates >> DA to aggregated UL L3-anchor segment "AG30::" associated with >> "AG20::". In this basic use case, just one UL L3-anchor SID with >> SL=0 is enough to do it so that there is no need to push another SRH >> to the packet in that PSP (Penultimate Segment Pop) operation. >> >> The aggregated L3-anchor node of "AG30::" segment does End.T process >> for the receiving packet according to the SRH that the node updates >> DA to D::1, decrement SL and lookup IPv6 table associated with >> "AG30::". In this basic use case, decremented SL is 0 so that the >> node does PSP operation of popped out the SRH from the packet and >> forward it. >> >> 6.2.2. Downlink >> >> In downlink, SRv6 node applies following SRv6 end point functions and >> transit behavior. >> >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 8] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> L3-Anchor: T.Insert >> >> L2-Anchor: End.B6 >> >> Access Point: End.X >> >> When the L3-anchor node receives a packet destine to "S::1" from a >> correspondant node "D::1", it does T.Insert process for the receiving >> packets to push a SRH with SID list (AG21::, S::1) and sets SL=1. >> The access point node update DA to "AG21::2" which indicates the >> aggregated DL L2-Anchor SID and forward the packet. >> >> The aggregated L2-anchor node of "AG21::" segment does End.B6 process >> for the receiving packet according to the segment. The node updates >> DA to aggregated DL access point segment "AG11::" associated with >> "AG21::". In this basic use case, just one aggregated DL access >> point SID with SL=0 is enough to do it so that there is no need to >> push another SRH to the packet in that PSP (Penultimate Segment Pop) >> operation. >> >> The aggregated access point node of "AG11::" segment does End.X >> process for the receiving packet according to the SRH that the node >> updates DA to S::1, decrement SL and forward the packet to the mobile >> node through its associated radio channel. In this basic use case, >> decremented SL is 0 so that the node does PSP operation of popped out >> the SRH from the packet and forward it. >> >> 6.3. Stateless Interworking >> >> SRv6 SID for stateless interworking function is encoding identifiers >> of corresponding tunnel in existing network as argument of the SID. >> This document define an SRv6 end function, "End.TM", and a transit >> behavior "T.Tmap" using following SID encoding: >> >> >> +----------------------+------+-------+-------+ >> |Locater of interwork | DA | SA | Tun-ID| >> +----------------------+------+-------+-------+ >> 128-a-b-c a b c >> >> >> Figure 3: Stateless Interworking SID Encoding >> >> In SRv6 to existing network direction, an endpoint of interworking >> allocates End.TM function to a SID prefix, say "T0::". When the >> endpoint receives packet and the active segment of the packet >> indicates that SID prefix, the endpoint does End.TM process that pops >> the SRH of the SID, and then the endpoint encaps the payload with the >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 9] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> encoded information in the SID which are tunnel identifier of tunnel >> header, source and destination IPv4 address of IPv4 header described >> in Figure 3. Then the endpoint send out the packet to the existing >> network along with its routing policy. >> >> In existing network to SRv6 network direction, existing network >> allocates IPv4 address spaces routed to interworking SRv6 network. >> SRv6 network allocates a domain-wise SID prefix for interworking >> segments, say "T1::". When a SRv6 endpoint connects to existing >> network receives packet destined to the allocated IPv4 address, the >> endpoint does T.Tmap behavior that decaps outer IPv4 and tunnel >> header, and then pushs an SRH with the SID which consists of the >> allocated SID prefix "T1::", source and destination addresses, and >> tunnel identifier as described in Figure 3. Then the endpoint send >> out the packet to the SRv6 network along with its routing policy. >> >> In case of IPv4 flow packet over the user-plane, the endpoint does >> IPv6 header encaps and decaps instead of SRH insert and pop process. >> The IPv6 header includes interworking segment SID in the SRH. >> >> Noted that to make sure stateless interworking, entities of control- >> plane in mobile management should cooperate with SRv6 user-plane >> settings. Further control-plane consideration is discussed in >> Section 8. >> >> 6.4. Rate Limit Function >> >> Mobile user-plane requires rate-limit feature. SID is able to encode >> limiting rate as an argument in SID. Multiple flows of packets >> should have same group identifier in SID when those flows are in an >> same AMBR group. This helps to keep user-plane stateless. That >> enables SRv6 endpoint nodes which are unaware from the mobile >> control-plane information. Encoding format of rate limit segment SID >> is following: >> >> >> +----------------------+----------+-----------+ >> | Locater of rate-limit| group-id | limit-rate| >> +----------------------+----------+-----------+ >> 128-i-j i j >> >> >> Figure 4: Stateless Interworking SID Encoding >> >> In case of j bit length is zero in SID, the node should not do rate >> limiting unless static configuration or control-plane sets the limit >> rate associated to the SID. >> >> >> [Sri] In addition to Rate Limiting, probably few other QoS elements have to >> supported here. >> >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 10] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> 7. Network Slicing Considerations >> >> Mobile network may be required to create a network slicing that >> represent a set of network resources and isolate those resource from >> other slices. User-plane functions represented as SRv6 segments >> would be part of a slice. >> >> To represent a set of user-plane function segments for a slice, >> sharing same prefix through those SIDs within the slice could be a >> straightforward way. SIDs in a network slice may include other type >> of functions in addition to the mobile user-plane functions described >> in this document, and underlay integration to meet SLA and quality >> requirements. >> >> While network slicing has been discussed in the IETF and other >> standardization bodies, what functionalities are required for network >> slicing in mobile user-plane is further study item and to be >> discussed. >> >> >> [Sri] I am not sure if slicing discussion is relevant here >> >> 8. Control Plane Considerations >> >> Mobile control-plane entities must allocate SIDs to user-plane >> function segments in case of those entities are distributed to >> accommodate in the SRv6 nodes, or those are separated from the >> endpoint but each of them corresponds to each SRv6 node. In latter >> case, control-plane entity must advertise allocated SID to the >> endpoint through some means which are out of scope of this document. >> >> Noted that in the case of aggregated segments for mobile user-plane >> functions, allocated SIDs for the segments can be pre-configured to >> SRv6 nodes. The control-plane should utilize those SIDs to manage >> mobility sessions especially when increasing number of sessions is >> expected to hit the upper-limit of the user-plane nodes. >> >> When a centralized controller interfaces to mobile control-planes is >> capable to allocate SIDs to the controlling SRv6 endpoints, the >> mobile control-planes just need to indicate the endpoint nodes and >> their user-plane functions to the controller. In this case, the >> controller must allocate appropriate SIDs for the user-plane roles to >> the indicated SRv6 endpoints. The controller must advertise >> allocated SIDs to the endpoints. To build centralized controller for >> mobile user-plane is out of scope of this document. >> >> However, to indicate endpoints and their user-plane functions from >> mobile control-plane to user-plane, the endpoint or the controller >> could take advantage of [I-D.ietf-dmm-fpc-cpdp]. It provides >> interface to the control-plane to manage the user-plane of mobile >> networks. >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 11] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> In case of stateless interworking, SID allocating entity needs to be >> aware SID prefix which interworking SRv6 endpoint and SRv6 domain >> allocate discussed in Section 6.3. The mobile control-plane also >> need to allocate tunnel endpoint IPv4 address to which corresponding >> interworking segment destined from existing user-plane that is also >> discussed in Section 6.3. >> >> 9. Security Considerations >> >> TBD >> >> 10. IANA Considerations >> >> This document has no actions for IANA. >> >> 11. References >> >> 11.1. Normative References >> >> [I-D.filsfils-spring-srv6-network-programming] >> Filsfils, C., Leddy, J., daniel.vo...@bell.ca, d., >> daniel.bern...@bell.ca, d., Steinberg, D., Raszuk, R., >> Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., >> Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., >> Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., >> Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. >> Camarillo, "SRv6 Network Programming", draft-filsfils- >> spring-srv6-network-programming-02 (work in progress), >> October 2017. >> >> [I-D.ietf-spring-segment-routing] >> Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., >> Litkowski, S., and R. Shakir, "Segment Routing >> Architecture", draft-ietf-spring-segment-routing-13 (work >> in progress), October 2017. >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, >> DOI 10.17487/RFC2119, March 1997, <https://www.rfc- >> editor.org/info/rfc2119>. >> >> 11.2. Informative References >> >> [I-D.ietf-dmm-fpc-cpdp] >> Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., >> Moses, D., and C. Perkins, "Protocol for Forwarding Policy >> Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09 >> (work in progress), October 2017. >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 12] >> Internet-Draft SRv6-mobile-uplane October 2017 >> >> >> [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., >> Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", >> RFC 5213, DOI 10.17487/RFC5213, August 2008, >> <https://www.rfc-editor.org/info/rfc5213>. >> >> [TS.29281] >> 3GPP, , "General Packet Radio System (GPRS) Tunnelling >> Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, >> September 2011. >> >> Authors' Addresses >> >> Satoru Matsushima >> SoftBank >> Tokyo >> Japan >> >> Email: satoru.matsush...@g.softbank.co.jp >> >> >> Clarence Filsfils >> Cisco Systems, Inc. >> Belgium >> >> Email: c...@cisco.com >> >> >> Miya Kohno >> Cisco Systems, Inc. >> Japan >> >> Email: mko...@cisco.com >> >> >> Daniel Voyer >> Bell Canada >> Canada >> >> Email: daniel.vo...@bell.ca >> >> >> >> >> >> >> >> >> >> >> >> >> Matsushima, et al. Expires May 3, 2018 [Page 13] >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
