LSR Working Group J. Dong Internet-Draft S. Bryant Intended status: Standards Track Huawei Technologies Expires: April 25, 2019 October 22, 2018 IGP Extensions for Segment Routing based Enhanced VPN draft-dong-lsr-sr-enhanced-vpn-01 Abstract Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. These applications require better isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. An enhanced VPN may form the underpin of 5G transport network slicing, and will also be of use in its own right. This document describes how Multi- Topology Routing (MTR) as described in RFC 5120, RFC 4915 and RFC5340, can be extended to signal the network resources allocated in the underlay network to construct the customized virtual networks for enhanced VPN services, together with the Segment Routing Identifiers (SIDs) used to identify and access the network resources allocated for each virtual network in the data plane. 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 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 April 25, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Dong & Bryant Expires April 25, 2019 [Page 1] Internet-Draft IGP Extensions for VPN+ October 2018 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 3. Overview of Approach . . . . . . . . . . . . . . . . . . . . 3 4. SR Virtual Topology with Resource Guarantee . . . . . . . . . 4 4.1. Topology specific Link Resource Allocation and Identification . . . . . . . . . . . . . . . . . . . . . 5 4.2. Topology specific Node Resource Allocation and Identification . . . . . . . . . . . . . . . . . . . . . 6 5. Multiple Services in SR Virtual Topology . . . . . . . . . . 6 5.1. Common Service Types . . . . . . . . . . . . . . . . . . 7 5.1.1. Best Effort . . . . . . . . . . . . . . . . . . . . . 7 5.1.2. Assured Bandwidth . . . . . . . . . . . . . . . . . . 7 5.1.3. Deterministic . . . . . . . . . . . . . . . . . . . . 8 6. Topology and Algorithm . . . . . . . . . . . . . . . . . . . 8 7. SRv6 Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Fast Repair . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. LAN interface . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 13.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The framework for an enhanced virtual private network (VPN+) is described in [I-D.dong-teas-enhanced-vpn]. Driven largely by needs arising from the 5G mobile network design, the concept of network slicing has gained traction. There is a need to create a VPN service with enhanced isolation and performance characteristics. Specifically, there is a need for a transport network to support a set of virtual networks, each of which provides the client with some dedicated (private) network resources drawn from Dong & Bryant Expires April 25, 2019 [Page 2] Internet-Draft IGP Extensions for VPN+ October 2018 a shared pool. The tenant of such a virtual network can require a degree of isolation and performance that previously could only be satisfied by dedicated networks. Additionally the tenant may ask for some level of control of their virtual networks e.g. to customize the service paths in their network slices. These properties cannot be met with pure overlay networks, as they require tighter coordination and integration between the underlay and the overlay network. [I-D.dong-teas-enhanced-vpn] provides the framework of enhanced VPN and describes the candidate component technologies. [I-D.dong-spring-sr-for-enhanced-vpn] describes how segment routing (SR) [I-D.ietf-spring-segment-routing] is used to construct the required virtual networks with the network resources allocated for enhanced VPN services. This document describes how Multi-Topology Routing (MTR), as described in [RFC5120] [RFC4915] and [RFC5340] , is extended to signal the resources allocated in the underlay to construct the virtual networks for enhanced VPN services, together with the segment routing identifiers (SIDs) used to identify and access the resource allocated for different virtual networks in the data plane. The mechanism is applicable to both SR with MPLS data plane and SR with IPv6 data plane (SRv6). 2. Specification of Requirements 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 [RFC2119]. 3. Overview of Approach To meet the requirement of enhance VPN services, a number of virtual networks can be created, each representing a subset of the underlay network topology and resources to be used by a specific customer. In a 5G context, each virtual network is considered as a network slice which serves one slice tenant. Depending on the service requirements, different virtual networks can either share the same physical links or nodes, or use separate links or nodes in the network, while the required level of isolation and performance SHOULD be guaranteed in both cases. IGP multi-topology routing can be seen as a candidate mechanism to create multiple network topologies in one network. Different from the traditional multi-topology mechanism, which only provides logical topological isolation, in the proposed mechanism network resources can be partitioned and allocated to different virtual network topologies to meet the isolation and performance requirements of Dong & Bryant Expires April 25, 2019 [Page 3] Internet-Draft IGP Extensions for VPN+ October 2018 enhanced VPN. Service in one virtual topology can be instructed to be processed only using the network resources allocated to this virtual topology. This is achieved by using multi-topology routing (MTR) together with segment routing, and extending the SR paradigm to use Segment Identifiers (SIDs) to identify different set of resources allocated from a particular network element (e.g. link or node). Different set of SIDs are associated with different virtual topologies, and are used to create the SID lists within different virtual topologies. In some cases, it is also possible for several virtual network topologies to share some network resources, this can be achieved by using the same SR SIDs between those topologies. The detailed mechanism of resource sharing will be described in a future version. Within one SR virtual network, one or more type of services can be deployed using the resources allocated to that topology, some of which may have different characteristics and require dedicated resources or special treatment. The concept is similar to the DS-TE model [RFC4124] of RSVP-TE based mechanism, while in this case the SR paradigm is applied, which avoids the introduction of per-path state into the network. In general this approach applies to both IS-IS and OSPF, while the specific protocol extensions and encodings are different. In the current version of this document, the required IS-IS extensions are described. The required OSPF extensions will be described in a future version. 4. SR Virtual Topology with Resource Guarantee As described in [I-D.ietf-isis-segment-routing-extensions], IS-IS TLV-222 (MT-ISN) and TLV-223 (MT IS Neighbor Attribute) have been enhanced to carry the Adj-SID sub-TLV, and TLV-235 (Multitopology IPv4 Reachability) and TLV-237 (Multitopology IPv6 IP Reachability) have been enhanced to carry the Prefix-SID sub-TLV. With these enhancements, dedicated Segment Identifiers (SIDs) can be assigned for each SR virtual network topology. The topology-specific SIDs can be used as distinguisher in packet forwarding of different topologies. This section specifies the necessary extensions to enable the deployment of resource guaranteed SR virtual topologies. Each virtual topology can be allocated with a particular partition of network resources from the underlay network, the SIDs can be used to identify the set of resources allocated for different virtual topologies on each involved network element. Dong & Bryant Expires April 25, 2019 [Page 4] Internet-Draft IGP Extensions for VPN+ October 2018 4.1. Topology specific Link Resource Allocation and Identification A network link can participate in one or multiple SR virtual topologies, each virtual topology is assigned with a dedicated adj- SID. In order to describe the amount of link resource allocated to a particular SR virtual topology, a new IS-IS sub-TLV called "SR Bandwidth" sub-TLV is defined: The SR-Bandwidth sub-TLV is an optional sub-TLV carrying the aggregated bandwidth allocated to a particular SR adj-SID, which is associated witha particular virtual topology. In the data plane, the allocated bandwidth and the associated functional components are identified by the adj-SID of the virtual topology. This sub-TLV may be advertised as a sub-TLV of the following TLVs: TLV-22 (Extended IS reachability) [RFC5305] TLV-23 (IS Neighbor Attribute) [RFC5311] TLV-141 (inter-AS reachability information) [RFC5316] TLV-222 (Multitopology IS)[RFC5120] TLV-223 (Multitopology IS Neighbor Attribute) [RFC5311] The SR bandwidth sub-TLV can appear at most once for a particular topology. Multiple SR Bandwidth sub-TLVs MAY be associated with a single IS neighbor. The following format is defined for the SR Bandwidth sub-TLV: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Bandwidth +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth Cont | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SR Bandwidth sub-TLV where: Type: TBD, to be assigned by IANA. Length: variable. The SR bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second. Dong & Bryant Expires April 25, 2019 [Page 5] Internet-Draft IGP Extensions for VPN+ October 2018 [I-D.ietf-teas-sr-rsvp-coexistence-rec] describes several options for traffic engineering in networks where RSVP-TE and SR LSPs coexist. Note that section 3.1 of [I-D.ietf-teas-sr-rsvp-coexistence-rec] proposes to partition the network bandwidth between RSVP-TE and SR. The can be considered as a special case of creating one default SR virtual topology with dedicated bandwidth allocated, so that the network resources and operation of SR are isolated from the RSVP-TE based LSPs. 4.2. Topology specific Node Resource Allocation and Identification A network node can participate in one or multiple SR virtual topologies, each virtual topology is assigned with a dedicated node- SID. In SR loose path forwarding, the topology specific node-SIDs can be used by transit network nodes to identify the virtual topology the packet belongs to, so as to steer the packet through the set of link resources allocated to the identified virtual topology. A prefix-SID sub-TLV describing the dedicated node-SID for each virtual topology is needed, this is supported in [I-D.ietf-isis-segment-routing-extensions] for SR using MPLS data plane. The mechanism for SRv6 is described in section 7. In addition, similar to the allocation of link resource to virtual topologies, it is possible to allocate a subset of nodal resources to a particular virtual topology to ensure end-to-end service delivery. The nodal resources can be identified by topology specific node-SIDs. During packet forwarding, the node SIDs can be used to steer a packet through the set of nodal resources allocated to this topology. Optional sub-TLVs describing the resources allocated at the node level for a particular virtual topology can be defined in future. The specification of nodal resources is for further study. 5. Multiple Services in SR Virtual Topology Within one SR virtual topology, one or more types of service can be deployed using the resources allocated to this virtual topology. Each service type can have specific resource constraints and characteristics. The concept is similar to the DS-TE model [RFC4124] of RSVP-TE based mechanism, while in this case the SR paradigm is applied, which avoids the introduction of per-flow state into the network. Some mechanism is needed to identify different service types and specify the different service characteristics within one virtual topology. The detailed protocol extensions will be provided in a future version. Dong & Bryant Expires April 25, 2019 [Page 6] Internet-Draft IGP Extensions for VPN+ October 2018 5.1. Common Service Types A service type is fundamentally the sum of the properties of a group of services. The authors considered specifically creating a number of specific service types within the protocol but concluded that this was meaningless. The following sections show how a number of well known service types can be constructed. 5.1.1. Best Effort Best effort service can be the only service type in a particular virtual topology. In this case, all of the resources allocated to this virtual topology instance are available to the best effort services. Where there are multiple service types being carried in a virtual topology, best effort service will be transmitted over the links and nodes when there is an opportunity. The maximum resources which can be used by best effort service may be constrained to a subset of the topology resource. The Traffic Class (TC) of the best effort service SHOULD be set to lower than any other service types. In the data plane, the SID and the Traffic Class value in the packet can be used to identify the service type and steer the best effor packets into the correct forwarding resources, such as queues. Best effort services may or may not be protected at the discretion of the network operator. 5.1.2. Assured Bandwidth An Assured Bandwidth service is one in which the bandwidth is assured but the latency is not. Thus, some bandwidth can be allocated to the assured bandwidth service, and traffic up to that bandwidth will be transmitted over the service, but the traffic may be delayed by other traffic. It is likely that the assured bandwidth service will be carried in a virtual topology together with other service types, such as the best effort service. The maximum resources which can be used by assured bandwidth service SHOULD be constrained to a subset of the topology resource. There will frequently be more than one assured bandwidth service running on a topology, and the Traffic Class (TC) could be used to determine how the various services compete for access to the link. Whilst the bandwidth is assured over the long term, over the short term it is not and such services will interact with similar and lower Dong & Bryant Expires April 25, 2019 [Page 7] Internet-Draft IGP Extensions for VPN+ October 2018 service classes in such a way that packet delay and jitter is not assured. In the data plane, the SID and the Traffic Class value in the packet can be used to identify the service type and priority and steer the assured bandwidth service packets into the correct forwarding resources, such as queues. 5.1.3. Deterministic A Deterministic service is a service that may have controlled delay/ jitter characteristics and/or an enhanced packet delivery assurance. Delay/Jitter may be addressable through the provision of sufficient bandwidth, or it may require some form of packet scheduling. Enhanced delivery assurance may require the use of packet replication and elimination mechanism. The design of a deterministic network is discussed in [I-D.ietf-detnet-architecture]. Note that delay protection and delivery protection are orthogonal characteristics and a service may provide just one of the characteristics or it may provide both. The details of a deterministic service will be provided in a future version. Such a service may be specified using the TLVs defined in [I-D.geng-detnet-info-distribution] 6. Topology and Algorithm In the proposed mechanism, SR is used with IGP multi-topology to create one or more SR virtual topologies, each associated with a set of network resources allocated for the virtual topology. The service paths used between nodes in one virtual topology are not constrained to be shorted path by IGP metric, and can be any non-looping path that best suits the needs of the service. These paths may be imposed by the network controller, or calculated using a distributed method. For example, different SR algorithms as defined in [I-D.ietf-isis-segment-routing-extensions] can be used within one virtual topology. The Flex-Algo mechanism defined in [I-D.ietf-lsr-flex-algo] may also be used in one virtual topology to meet different service requirements. 7. SRv6 Considerations The mechanism to create virtual network topologies with guaranteed resource using SRv6 data plane is similar to SR with MPLS data plane, while there are some differences to be considered. As described in [I-D.filsfils-spring-srv6-network-programming], an SRv6 SID is represented with the format of LOC:FUNCT, where LOC is Dong & Bryant Expires April 25, 2019 [Page 8] Internet-Draft IGP Extensions for VPN+ October 2018 the locator field, and FUNCT is the function field. the Locator of the SID is routable and leads to the node which instantiates that SID. The function of the SID is an opaque identification of a local function bound to the SID, which means the function field can only be parsed by the node which instantiates the SRv6 SID. In order to build multiple virtual topologies with SRv6 data plane, all the nodes in one particular topology must have consistent forwarding behavior. On one node which participate in multiple topologies, it MUST to be able to distinguish packets of different topologies to perform correct packet forwarding. Taking the above into consideration, each node MUST allocate dedicated SRv6 locator for each virtual topology it participates in, the mapping of locator to topology MUST be advertised into the network. For one virtual topology, all the SRv6 SIDs on a node MUST be allocated from the SID space identified by the topology-specific locator which is associated with the topology. In the latest version of [I-D.bashandy-isis-srv6-extensions], the SRv6 Locator TLV is defined to advertise the locators for each topology/algorithm pair. The SRv6 SIDs are defined as sub-TLVs of SRv6 Locator TLV, except for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a specific Neighbor/Link. Such protocol extensions can support the advertisement of topology-specific locators, and the SRv6 SIDs which inherits the topology information from the locator. In order to advertise the SRv6 End.X SID/LAN End.X SIDs associated with different topologies the node participates in, the SRv6 End.X SID sub-TLV as defined in [I-D.bashandy-isis-srv6-extensions] MUST be advertised as sub-TLVs in the MT Intermediate Systems TLV (type 222). The SR bandwidth sub-TLV as defined in this document SHOULD also be carried in the MT Intermediate Systems TLV. 8. Fast Repair In some instances it is desirable to provide some form of fast repair for a failed link or node. The methods available fall into two categories, end-to-end, for example 1+1, and IP fast reroute. Whichever of these is used, it is desirable that the repair path provides the same level of service to the tenant as the tenant's normal service. This would mean that the repair path needs to be constrained to the tenant's topology and resource, or to some repair topology and resource reserved exclusively for that tenant for the duration of the repair. The normal way that IPFRR operates is that the point of local repair (PLR) calculates the repair path based on the information flooded by the routing protocol. How the PLR can maintain the level of service through the repair is for further study. Dong & Bryant Expires April 25, 2019 [Page 9] Internet-Draft IGP Extensions for VPN+ October 2018 9. LAN interface The use of multi-point to multi-point (MP2MP) interfaces is currently out of scope for this design. A LAN interface MUST be used in point to point mode. Note support for MP2MP may be needed in the future, and this is for further study. 10. Security Considerations This document introduces no additional security vulnerabilities to IS-IS and OSPF. The mechanism proposed in this document is subject to the same vulnerabilities as any other protocol that relies on IGPs. 11. IANA Considerations This document requests IANA to allocate a sub-TLV type as defined in Section 4 from "Sub-TLVs for TLVs 22, 23, 25, 141, 222 and 223" registry. Value Description Reference ----- -------------------- ------------- TBA1 SR bandwidth sub-TLV This document Per TLV information where SR bandwidth sub-TLV can be part of: TLV 22 23 25 141 222 223 --- -------------------- y y n y y y 12. Acknowledgments The authors would like to thank Mach Chen, Robin Li and Dean Cheng for the review and discussion of this document. 13. References 13.1. Normative References [I-D.dong-spring-sr-for-enhanced-vpn] Dong, J., Bryant, S., Li, Z., and T. Miyasaka, "Segment Routing for Enhanced VPN Service", draft-dong-spring-sr- for-enhanced-vpn-01 (work in progress), July 2018. Dong & Bryant Expires April 25, 2019 [Page 10] Internet-Draft IGP Extensions for VPN+ October 2018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . 13.2. Informative References [I-D.bashandy-isis-srv6-extensions] Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene, "IS-IS Extensions to Support Routing over IPv6 Dataplane", draft-bashandy-isis-srv6-extensions-01 (work in progress), September 2017. [I-D.dong-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., and T. Miyasaka, "A Framework for Enhanced Virtual Private Networks (VPN+)", draft-dong-teas-enhanced-vpn-02 (work in progress), October 2018. [I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-filsfils-spring-srv6-network- programming-05 (work in progress), July 2018. [I-D.geng-detnet-info-distribution] Geng, X. and M. Chen, "IGP-TE Extensions for DetNet Information Distribution", draft-geng-detnet-info- distribution-01 (work in progress), September 2017. Dong & Bryant Expires April 25, 2019 [Page 11] Internet-Draft IGP Extensions for VPN+ October 2018 [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- detnet-architecture-04 (work in progress), October 2017. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", draft-ietf-isis- segment-routing-extensions-15 (work in progress), December 2017. [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- algo-00 (work in progress), May 2018. [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-15 (work in progress), January 2018. [I-D.ietf-teas-sr-rsvp-coexistence-rec] Sitaraman, H., Beeram, V., Minei, I., and S. Sivabalan, "Recommendations for RSVP-TE and Segment Routing LSP co- existence", draft-ietf-teas-sr-rsvp-coexistence-rec-04 (work in progress), May 2018. [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, DOI 10.17487/RFC4124, June 2005, . Authors' Addresses Jie Dong Huawei Technologies Email: jie.dong@huawei.com Stewart Bryant Huawei Technologies Email: stewart.bryant@gmail.com Dong & Bryant Expires April 25, 2019 [Page 12]