Network Working Group Z. Li Internet-Draft I. Milojevic Intended status: Informational Z. Zhuang Expires: April 19, 2016 Huawei Technologies October 17, 2015 Segment Path Programming (SPP) draft-li-spring-segment-path-programming-00 Abstract Segment Routing for unicast traffic has been proposed to cope with the usecases in traffic engineering, fast re-reroute, service chain, etc. The document generalizes more use cases based on segment and proposes the concept of Segment Path Programming. In the field of Segment Path Programming: 1. The Segment used in the programmed segment path is not only used in the forwarding plane, but also used in the control plane. 2. The programmed segment path is not only used in the transport layer, but also used in the service layer. Accordingly this document proposes use cases, architecture and protocol extension requirements for the Segment Path Programming (SPP). Requirements Language 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]. 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 April 19, 2016. Li, et al. Expires April 19, 2016 [Page 1] Internet-Draft Segment Path Programming (SPP) October 2015 Copyright Notice Copyright (c) 2015 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 (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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Redefinition of Segment . . . . . . . . . . . . . . . . . . . 3 3.1. Application of Segment in Control Plane and Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Application of Segment in Reachability and Service Process . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Definition of Segment Path Programming Path . . . . . . . . . 6 5. Usecases of Segment Path Programming . . . . . . . . . . . . 7 5.1. Flexible Service Process Combination . . . . . . . . . . 7 5.2. Node Segment for Synonymous Flow Label . . . . . . . . . 8 5.3. Steering Traffic without Mapping Segment to Label . . . . 8 5.4. Centralized Mapping Service to Tunnels . . . . . . . . . 9 6. Framework of Service-Oriented MPLS Path Programming . . . . . 11 6.1. Central Control for MPLS Path Programming . . . . . . . . 11 6.2. Protocol Extensions Requirements . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Segment Routing [I-D.ietf-spring-segment-routing] for unicast traffic has been proposed to cope with the usecases in traffic engineering, fast re-reroute, service chain, etc. The document generalizes more use cases based on segment and proposes the concept of Segment Path Programming. In the field of Segment Path Programming: 1. The Segment used in the programmed segment path is not only used in the Li, et al. Expires April 19, 2016 [Page 2] Internet-Draft Segment Path Programming (SPP) October 2015 forwarding plane, but also used in the control plane. 2. The programmed segment path is not only used in the transport layer, but also used in the service layer. Accordingly this document proposes use cases, architecture and protocol extension requirements for the Segment Path Programming (SPP). 2. Terminology BGP: Border Gateway Protocol L2VPN: Layer 2 VPN L3VPN: Layer 3 VPN SPP: Segment Path Programming SR-path: Segment Routing Path SRGB: SR Global Block 3. Redefinition of Segment 3.1. Application of Segment in Control Plane and Forwarding Plane In the existing segment routing, the segment will be applied to the MPLS forwarding plane directly. In the MPLS architecture, the global segment such as node segment will be mapped to MPLS label since SRGB will be defined as the set of local labels reserved for global segments and the local segment will be a local label outside the SRGB. In fact, the segment can be only used in the control plane instead of mapping to the forwarding plane. In the usecase, the segment is just an indicator for specific process which can be used for the application of Segment Path Programming. For example, node segment in the Segment Routing mapped in the control plane and forwarding plane in the MPLS architecture is shown in the following figure. Li, et al. Expires April 19, 2016 [Page 3] Internet-Draft Segment Path Programming (SPP) October 2015 Control Plane: +---------+ +------------+ | Segment | | | | | = | Label | | ID | | | +---------+ +------------+ Forwarding Plane: +--------+------------+ +------------+-------------------------+ | | Forwarding | | Forwarding | Forwarding Information | | Label | | --> | | to | | | Index | | Index | Specified Node | +--------+------------+ +------------+-------------------------+ Figure 1: Node Segment in Segment Routing In the Segment Path Programming, the node segment can be enhanced to support following mapping in the control plane and forwarding plane even in the MPLS architecture. Control Plane: +---------+ +------------+ | Segment | | Forwarding | | | --> | | | ID | | Index | +---------+ +------------+ Forwarding Plane: +------------+-------------------------+ | Forwarding | Forwarding Information | | | to | | Index | Specified Node | +------------+-------------------------+ Figure 2: Enhanced Node Segment in Segment Path Programming In this mapping, the Segment ID can map to the forwarding entry to specific node. But it is only an indicator in the control plane which can be used for possible applications. When receive the mapping information between the application and the Segment ID, the network node will install additional forwarding entry as follows which map the application information to the forwarding information specified by the segment ID. Li, et al. Expires April 19, 2016 [Page 4] Internet-Draft Segment Path Programming (SPP) October 2015 Control Plane: Mapping Information +--------+------------+ | App | Segment | | | | | Info | ID | +--------+------------+ Forwarding Plane: +----------+------------+ +------------+-------------------------+ | | Forwarding | | Forwarding | Forwarding Information | | App Info | | --> | | to | | | Index | | Index | Specified Node | +----------+------------+ +------------+-------------------------+ Figure 3: Mapping App to Segment in Segment Path Programming The application information in the forwarding entry should be derived from the packet received by the network nodes such as the destination IP/MAC address, the source IP/MAC address, the port number, the protocol number, etc. It can also be the MPLS label. In order to support the enhanced segment in the Segment Programming Path, whether to map the Segment to MPLS label can be determined by the local policy of the network node. Protocol extensions can also be introduced to specify if the Segment maps to the MPLS label when advertised the information of SRGBs or all kinds of Segments. 3.2. Application of Segment in Reachability and Service Process In the existing Segment Routing, in the MPLS architecture the segment will be mapped to the label which is always the indicator of reachability to the specific node, the specific agency, etc. More types of Segments which indicates the reachability can be introduced according to existing MPLS forwarding plane. Since these segments represent reachability in the network, they can be used for traffic steering. These segments includes: -- Node Segment -- Agency Segment -- AS (Autonomous System) Segment -- Anycast Segment -- Multicast Segment Li, et al. Expires April 19, 2016 [Page 5] Internet-Draft Segment Path Programming (SPP) October 2015 -- Tunnel Segment -- VPN Segment -- etc. As the development of Segment Routing, the service segment is introduced to represent the specific service process. It can be used for some new application scenarios such qw the Service Function Chain (SFC). For the service process in the traditional IP/MPLS fowarding plane, it can also be indicated by different types of segments. This provides the possibility to flexibly combine these segment to set up a Segment Path to represent a series of service process in the network on the specific flow instead of only steering traffic. These Segments can represent different service process in the forwarding plane as follows: -- OAM Segment -- ECMP (Equal Cost Multi-Path) Segment -- QoS Segment -- Bandwidth-Guarantee Segment -- Security Segment -- Multi-Topology Segment -- etc. 4. Definition of Segment Path Programming Path Owing to more types of segments and flexible application of segment in the control plane and the forwarding plane, there will be powerful capability to combine these segments which can be used to steering traffic or provide flexible service process to satisfy different service requirement for specific flows in the network. We call such combination of segments as Segment Path and the flexible combining of segments as Segment Path Programming. Segment Routing ([I-D.ietf-spring-segment-routing]) is a typical example of Segment Path Programming. There can be multiple layers for Segment Path Programming which are shown in the following figure: Li, et al. Expires April 19, 2016 [Page 6] Internet-Draft Segment Path Programming (SPP) October 2015 +---+ +---+ +--+ | | +---+ +---+ +---+ | | +--+ |CE|----|PE1|----| P |----| P |----| P |----|PE2|----|CE| +--+ | | +---+ +---+ +---+ | | +--+ +---+ +---+ Service-oriented Segment Path Programming (SoSPP) o--------o--------- Service Layer------------o--------o o--------- Network Layer -----------o Transport-oriented Segment Path Programming (Segment Routing) o-------o--------o---------o-------o Transport Layer o-----o o-----o o-----o o-----o o-----o o-----o Link Layer Figure 4: Multiple Layers of Segment Path Programming Now the segment routing is to provide the source packet routing in the transport layer or the link layer for traffic steering . We can call such type of source packet routing as Transport-Oriented Segment Path Programming. There can be more application scenarios which need the segment path to respresent the service processes in the service layer or network layer. We call these types of source packet routing as Service-Oriented Segment Path Programming. 5. Usecases of Segment Path Programming 5.1. Flexible Service Process Combination The following figure shows the usecase of Segment Path Programming to combine service segments according to the service requirements on the traffic which can be specified by the traditional BGP VPN prefix. The combination of these service segments represent the required ECMP, QoS and OAM process. Li, et al. Expires April 19, 2016 [Page 7] Internet-Draft Segment Path Programming (SPP) October 2015 Traditional Label Binding for VPN Prefix: +----------+----------+ | VPN |VPN Prefix| | Prefix | Label | +----------+----------+ Additional Segment Path Information: +----------+----------+----------+ | ECMP | QoS | OAM | | Segment | Segment | Segment | +----------+----------+----------+ If the network node maps the corresponding segment to MPLS label, the forwarding entry can be as follows: +----------+ +----------+----------+----------+----------+ |VPN Prefix| | Entropy | QoS | OAM |VPN Prefix| Transport Tunnel | | --> | Label | Label | Label | Label | ---> determined by +----------+ +----------+----------+----------+----------+ BGP Nexthop 5.2. Node Segment for Synonymous Flow Label Synonymous flow label has been proposed by [I-D.bryant-mpls-synonymous-flow-labels] to solve the issue of the measurement of packet loss for multipoint-to-point LSP. Node segment advertised in the Segment Routing can be used as the flow label. In the scenario of performance measurement the flow label can only be interpreted by network node to identify the source of the flow other than set up the MPLS forwarding entry for the node segment in the scenario of segment routing. So when advertise the node segment information on the usage of the node segment can also be carried or the local policy can be introduced to determine the application of the node segment. Then the segment path can be set up based on such node segment for the purpose of performance measurement. 5.3. Steering Traffic without Mapping Segment to Label The following figure shows the usecase of Segment Path Programming to steer traffic which can be specified by the traditional BGP prefix. Li, et al. Expires April 19, 2016 [Page 8] Internet-Draft Segment Path Programming (SPP) October 2015 Traditional BGP Prefix: +----------+ | BGP | | Prefix | +----------+ Additional Segment Path Information: +----------+----------+ | Agency | Node | | Segment | Segment | +----------+----------+ If these segments are not applied in the MPLS forwarding plane, the Segment Path will be explained as steering traffic specified by the BGP prefix to reach specific node (determined by the Node Segment) through specific local link (determined by the Agency Segment). The corresponding fowarding entry will be as follows: +----------+------------+ +------------+---------------+--------------------+ | BGP | Forwarding | | Forwarding | Next Hop | Outgoing Interface | | | | --> | | determined by | determine by | | Prefix | Index | | Index | Node Segment | Link Segment | +----------+------------+ +------------+---------------+--------------------+ 5.4. Centralized Mapping Service to Tunnels In the transport layers, there can be multiple tunnels with different constraints to one specific destination. In the traditional way, the tunnel is set up by the distributed forwarding nodes. As the PCE- initiated LSP setup [I-D.ietf-pce-pce-initiated-lsp]is introduced, the tunnel setup can be triggered by the central controlled way. In order to satisfy the different service requirements, it is necessary to provide the capability to flexibly map the service to different tunnels. Since the central control point has enough information based on the whole network view, it can be an effective way to map the service to the tunnel by the central point and advertise the mapping information to the end-points of the service to guide the mapping in the forwarding node. The method to implement mapping service to tunnels can directly introduce the tunnel attribute to specify the tunnel proposed by [I-D.li-idr-mpls-path-programming]. [I-D.li-spring-tunnel-segment] proposes one new type of segment, Tunnel Segment, which can provide an alternative way to implement mapping service to tunnels. In the following figure, the central controller can trigger to set up the MPLS TE tunnels through PCE-initiated LSP and allocate Segment ID for the tunnel in the Node-1. Li, et al. Expires April 19, 2016 [Page 9] Internet-Draft Segment Path Programming (SPP) October 2015 +------------+ | Central | | Controller | +------------+ ^ Tunnel Binding | SID (Z) | .-----. | ( ) V .--( )--. +-------+ ( ) +-------+ | |_( IP/MPLS Network )_| | |Node-1 | ( ================> ) |Node-2 | +-------+ (MPLS TE/IP Tunnel) +-------+ '--( )--' ( ) '-----' Figure 5: Using Tunnel Segment for Mapping Service to Tunnel Without applying the segment to MPLS label the Node-1 can set up the following mapping for the tunnel segment: Control Plane: +---------+ +------------+ | Segment | | Forwarding | | | --> | | | ID | | Index | +---------+ +------------+ Forwarding Plane: +------------+-----------------------+ | Forwarding | Tunnel Forwarding | | | | | Index | Information | +------------+-----------------------+ Figure 6: Enhanced Node Segment in Segment Path Programming Then the central controller can advertise following Segment Path information for the flow which can be specified by the traditional BGP prefix. Li, et al. Expires April 19, 2016 [Page 10] Internet-Draft Segment Path Programming (SPP) October 2015 Traditional BGP Prefix: +----------+ | BGP | | Prefix | +----------+ Additional Segment Path Information: +----------+ | Tunnel | | Segment | +----------+ Then the following forwarding entry can be set up for the specified BGP prefix to steer traffic to specific tunnel in the Noed-1. +----------+------------+ +------------+----------------------+ | BGP | Forwarding | | Forwarding | Tunnel Forwarding | | | | --> | | | | Prefix | Index | | Index | Information | +----------+------------+ +------------+----------------------+ 6. Framework of Service-Oriented MPLS Path Programming 6.1. Central Control for MPLS Path Programming Central control plays an important role in Segment Path Programming shown in the figure 7. There are two important functionalities for the central controller: 1. Central controlled Segment allocation/collection: Segment can be allocated centrally for specific usage. Or central controller can collect the segment binding information from the network nodes. BGP/PCEP/IGP extensions can be introduced to distribute or collect the segment binding information. 2. Central controlled Segment Path Programming: Central controller can calculate path in a global network view and implement the Segment Path Programming based on the collected information of segments to satisfy different requirements of service flows. BGP/PCEP extensions can be introduced to download the Segment Path for the Service/ Network layer or Transport/Link layer. Li, et al. Expires April 19, 2016 [Page 11] Internet-Draft Segment Path Programming (SPP) October 2015 +-------------------+ | Central | | Controller | |----------|(Path Calculation |--------| | | /Path Programming)| | | +-------------------+ | | / | \ | Segment Path / Segment \ Segment Path | / | \ | | Segment | Segment | | / | \ | | / | \ | | / | \ | +--------+ +--------+ +--------+ | CLIENT | | CLIENT | | CLIENT | | | ...... | | ...... | | | (PE) | | (P) | | (PE) | | | | | | | +--------+ +--------+ +--------+ Figure 7: Central Control for Segment Path Programming 6.2. Protocol Extensions Requirements REQ 01: BGP/PCEP/IGP extensions should be introduced to distribute Segment binding for specific usage from the central controller to other client nodes. REQ 02: BGP/PCEP/IGP extensions should be introduced to collect Segment binding for specific usage from the client nodes to the central controller. REQ 03: BGP extensions should be introduced to download Segment (stack) for Segment Path of the service/network layer. REQ 04: PCE extensions should be introduced to download Segment (stack) for Segment Path of the transport layer. REQ 05: Protocol extensions should be introduced to specify the application of SRGB or Segment which means if the segment is applied to MPLS forwarding plane. 7. IANA Considerations This document makes no request of IANA. Li, et al. Expires April 19, 2016 [Page 12] Internet-Draft Segment Path Programming (SPP) October 2015 8. Security Considerations TBD. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [I-D.bryant-mpls-synonymous-flow-labels] Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- bryant-mpls-synonymous-flow-labels-01 (work in progress), July 2015. [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-04 (work in progress), April 2015. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and r. rjs@rob.sh, "Segment Routing Architecture", draft- ietf-spring-segment-routing-06 (work in progress), October 2015. [I-D.li-idr-mpls-path-programming] Li, Z., "BGP Extensions for Service-Oriented MPLS Path Programming (MPP)", draft-li-idr-mpls-path-programming-01 (work in progress), March 2015. [I-D.li-spring-tunnel-segment] Li, Z. and N. Wu, "Tunnel Segment in Segment Routing", draft-li-spring-tunnel-segment-00 (work in progress), September 2015. Authors' Addresses Li, et al. Expires April 19, 2016 [Page 13] Internet-Draft Segment Path Programming (SPP) October 2015 Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Igor Milojevic Huawei Technologies Poland-Warsaw-TULIPAN HOUSE, UL. DOMANI EWSKA 50, 02-672 Warsaw Poland Email: Igor.Milojevic@huawei.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Li, et al. Expires April 19, 2016 [Page 14]