SPRING WG Ting. Liao Internet-Draft Bo. Wu Intended status: Standards Track Fangwei. Hu Expires: January 7, 2016 ZTE Corporation Bhumip. Khasnabish ZTE TX Inc. July 6, 2015 SPRING SID Allocation draft-lw-spring-sid-allocation-02.txt Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). And a segment is identified by a Segment Routing ID (SID). This document proposes a method to reduce the SID configuration in a SR domain. Only the selected SR nodes which named Segment Routing Management Nodes (SRMNs) are configured by NMS, while other SRs in the domain need zero-SR-configuration. 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 January 7, 2016. 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 Liao, et al. Expires January 7, 2016 [Page 1] Internet-Draft SPRING SID Allocation July 2015 (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 Abbreviations . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SID generation and allocation . . . . . . . . . . . . . . . . 4 4.1. SID generation . . . . . . . . . . . . . . . . . . . . . 5 4.2. SID allocation . . . . . . . . . . . . . . . . . . . . . 5 5. IGP extension . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. The ISIS SID-allocation TLV . . . . . . . . . . . . . . . 6 5.2. The OSPF SID-Allocation TLV . . . . . . . . . . . . . . . 7 6. SID Allocation Ability extension . . . . . . . . . . . . . . 8 6.1. The ISIS SR Capabilities Sub-TLV extension . . . . . . . 8 6.2. The OSPF SR Capabilities TLV extension . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). And a segment is identified by a Segment Identifier (SID). A segment can be encoded as a MPLS label or an IPv6 address. Typically a SID is configured by NMS and it very rarely changes. When the SID configured, each node could send out its IGP TLV extensions which had described in [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]. In some situation where users expect to simply plug in a SR node and have it automatically enable Segment Routing. One of the use cases is described in [I-D.kh-spring-ip-ran-use-case], with hundreds of CSGs in an IP RAN network, the configuration assigned by NMS could be very complexity. And with the complexity of the network such as nodes adding and removing, the management on NMS is a hard work. If the CSGs can plug and play, it will be very useful. And the CSGs Liao, et al. Expires January 7, 2016 [Page 2] Internet-Draft SPRING SID Allocation July 2015 could be uploaded with zero-touch currently, by generating the ip address from MAC by default algorithm and with the ospf process default uploaded, have a mechanism to ensure the uniqueness of ip. Then the CSGs could be connected, and the topology will be collected by the ASGs. With the mechanism described in this draft, there is no SR configuration on the CSGs, the CSGs could be zero-touch still, reduce the complexity of SR related configuration and reduce the complexity of NMS. This draft describes a mechanism to optimize SID allocation operation. 2. Conventions and Abbreviations 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] . The following notations and abbreviations are used throughout this draft. ASG: Aggregation Site/Service Gateway. BS: Base Station. CSG: Cell Site Gateway. IP RAN: Internet Protocol RAN RAN: Radio Access Network. RNC: Radio Network Controller. RSG: Radio Service Gateway. SR: Segment Routing. SID: Segment Identifiers. 3. Motivation As described in [I-D.kh-spring-ip-ran-use-case] , the IP RAN network scenario is shown in the figure 1. Liao, et al. Expires January 7, 2016 [Page 3] Internet-Draft SPRING SID Allocation July 2015 ---------------- / \ / \ +------+ +----+ +----+ +----+ +----+ | BS |---|CSG1| |ASG1|------|RSG1|-----|RNC1| +------+ +-+--+ +----+ +----+ +----+ | Access | Aggration | | Domain | Domain | +------+ +-+--+ +----+ +----+ +----+ | BS |---|CSG2| |ASG2|------|RSG2|-----|RNC2| +------+ +----+ +----+ +----+ +----+ \ / \ / -------------- Figure 1 IP RAN Network Scenario There are hundreds of CSGs (Cell Site Gateway) and a few sets of ASGs (Aggregation Site/Service Gateway) in the Access Domain of an IP RAN network. With the increase of mobile Internet traffic, more CSGs could be added to the Access Domain, and CSGs could be installed in wide area. So, there is a great need to do little or no configuration on CSGs to avoid configuration operation. In current IP RAN implementation, as the CSGs could be uploaded with zero-touch, by generating the ip address from MAC by default algorithm and with the ospf process default uploaded, have a mechanism to ensure the uniqueness of ip. Then the CSGs could be connected, and the topology will be collected by the ASGs. ASGs are configured by NMS, and the configurations on CSGs are configured by ASGs, typical MPLS protocols like LDP protocol is used. With SR replacing LDP, complexity in LDP configuration could be greatly reduced. But in current SR process, each SR node should be configured by NMS, including the SR related configurations such as SIDs and SR algorithm and SR global blocks. If the configuration on CSGs still need to be came from ASGs, a specific mechanism is proposed in this draft to fulfill this requirement. Like the network in the above figure, an ASG or both the ASGs could be selected as a SID management node to advertise CSGs and ASGs SID mapping to the whole SR domain. 4. SID generation and allocation In the proposed mechanism, one or more Segment Routing Management Nodes (SRMNs) reside at SR nodes and advertise the SID mapping information for the various prefix associated with the SR nodes in the SR domain. Liao, et al. Expires January 7, 2016 [Page 4] Internet-Draft SPRING SID Allocation July 2015 4.1. SID generation The NMS configure the SRGB block to the SRMN. The SRMN will generate SIDs to other nodes'router-ids and to the router-id of itself, the generation principle based on the configuration of the NMS or the default generation rule, the default allocation rule MAY be based on the numerically higher router-id with the higher SID allocated. 4.2. SID allocation As described in section 3, when the SR node is powdered on, the IGP protocol as default function loaded, each node flooding out each router information in ISIS LSP or OSPF LSA when the ISIS adjacency or OSPF adjacency relations formed, and every node will acquire the router-ids of other nodes from the information (such as the IP address of router id) of IGP TLV. Then the SRMN generates the SIDs mapping to the router-ids and allocates the SIDs to each SR node by using the extension of SID Allocation TLV or the SID Binding TLV(as described in [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]. )in the IGP packet, flooding the packet out. In the SID Allocation TLV, it carries the router-id and SID mapping, and related algorithm type, and related multi-topology number. And in one SID-Allocation TLV, it can carry one or more IP addresses. Optionally, If more than one SRMN assigned by the NMS, the SRMNs May flood out another extension which indicating having the capability to allocate SID, this extension is called the SR Allocation Ability extension and be included in the SR capabilities. When other SR nodes receive more than one of the SRMN advertised the extension, the SR node could decide how to choose the Allocated SID, the choosing principle is based on the value of SRMNs' router id or system id, the maximum or the minimum value is chosen, and the SID allocated by the maximum or minimum id's SRMN be chosen. When each SR node received the IGP packet with the SID Allocation TLV, it will know which SID is allocated to itself, and then the SR node sends out the prefix-SID sub-TLV in its IGP packet flooding out in the IGP area. Then each SR node will know the other SR nodes' SID, and the related algorithm will calculate the path to each SR node's SID. With the automatic uniform allocation by the SRMN in the IGP area, when a new node is added, the SRMN will know which SIDs had been allocated, and allocate an unused SID in the SRGB to the new node's IP address. And if the node has moved, the SRMN will delete the related SID to the moving node's IP address and recycle this SID. Liao, et al. Expires January 7, 2016 [Page 5] Internet-Draft SPRING SID Allocation July 2015 The SID uniqueness is managed on the SRMN. If more than one SRMN assigned by the NMS, the SR Allocation Ability extension will be used, the detail information is described in section 4.2. 5. IGP extension The SID Allocation TLV MAY be originated by any assigned router in an IS-IS domain or an OSPF domain. As [I-D.ietf-ospf-segment-routing-extensions] defines OSPF extension for the purpose of the advertisements of various SID values, new Opaque LSAs [RFC5250] are defined in [I-D.ietf-ospf-prefix-link-attr]. But the SID Allocation TLV is no need to binding with the prefix of the router or re-advertised by the router. The SID Allocation TLV may be advertised in a new Opaque LSA. 5.1. The ISIS SID-allocation TLV The SID Allocation TLV has Type TBD, and has the following format: 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 | Flags | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | Algorithm | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | SID (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 ISIS SID-allocation TLV o Type: TBD. o 1 octet of Length: variable, in bytes. o 1 octet of flags. o 1 octets of Range: The 'Range' field provides the ability to specify a range of addresses and their allocated SIDs. It is essentially a compression scheme to allocate a continuous Prefix and their continuous, corresponding SID/Label Block. If a single SID is advertised then the range field MUST be set to one. For range advertisements > 1, the number of addresses that need to be Liao, et al. Expires January 7, 2016 [Page 6] Internet-Draft SPRING SID Allocation July 2015 mapped into a Prefix-SID and the starting value of the Prefix-SID range. o 1 octet of MT-ID: Multi-Topology ID (as defined in [RFC4915]). o 1 octet of Algorithm: one octet identifying the algorithm type the Prefix-SID is associated. The following value is defined by this document: * 0: IGP metric based Shortest Path Tree (SPT). o 4 octet of Prefix. o 4 octet of SID: according to the flags, it contains: * A 32 bit index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1. * A 24 bit label where the 20 rightmost bits are used for encoding the label value. 5.2. The OSPF SID-Allocation TLV The SID Allocation TLV has Type TBD, and has the following format: 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 | Flags | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | Algorithm | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | SID (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 OSPF SID-allocation TLV o Type: TBD. o 1 octet of Length: variable, in bytes. o 1 octet of flags. o 1 octets of Range: The 'Range' field provides the ability to specify a range of addresses and their allocated SIDs. It is essentially a compression scheme to allocate a continuous Prefix Liao, et al. Expires January 7, 2016 [Page 7] Internet-Draft SPRING SID Allocation July 2015 and their continuous, corresponding SID/Label Block. If a single SID is advertised then the range field MUST be set to one. For range advertisements > 1, the number of addresses that need to be mapped into a Prefix-SID and the starting value of the Prefix-SID range. o 1 octet of MT-ID: Multi-Topology ID (as defined in [RFC4915]) o 1 octet of Algorithm: one octet identifying the algorithm type the Prefix-SID is associated. The following value is defined by this document: * 0: IGP metric based Shortest Path Tree (SPT). o 4 octet of Prefix. o 4 octet of SID: according to the flags, it contains: * A 32 bit index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1. * A 24 bit label where the 20 rightmost bits are used for encoding the label value. 6. SID Allocation Ability extension With the compatibility consideration, nodes in the SR domain need to advertise its SR data-plane capability by using SR-Capabilities TLV in OSPF area or SR-Capabilities sub-TLV in ISIS area. So the assigned router advertises its SID allocation capability, it may be included in SR-Capabilities Sub-TLV of ISIS or in SR-Capabilities TLV of OSPF, with the Special Flag to indicate it is an assigned router. 6.1. The ISIS SR Capabilities Sub-TLV extension The ISIS SR Capabilities Sub-TLV (Type: TBD) is optional, MAY appear multiple times inside the Router Capability TLV and has following format: Liao, et al. Expires January 7, 2016 [Page 8] Internet-Draft SPRING SID Allocation July 2015 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 | Flags | Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range (cont.) | SID/Label Sub-TLV (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 ISIS SR Capabilities Sub-TLV o Type: TBD. o 1 octet of Length: variable, in bytes. o 1 octet of flags, the following are defined: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|V|A| | +-+-+-+-+-+-+-+-+ where: o I-Flag: IPv4 flag. If set, then the router is capable of outgoing IPv4 encapsulation on all interfaces. o V-Flag: IPv6 flag. If set, then the router is capable of outgoing IPv6 encapsulation on all interfaces. o A-Flag: Allocation flag. If set, then the router is capable of allocating SID capability. 3 octets of Range: defining the number of values of the range from the starting value defined in the SID/Label Sub-TLV. SID/Label Sub-TLV: SID/Label value as defined in [I-D.ietf-isis-segment-routing-extensions]. 6.2. The OSPF SR Capabilities TLV extension As described in [I-D.ietf-ospf-segment-routing-extensions], the SID/ Label Range TLV as an additional router capability of SR, it is a top-level TLV of the Router Information Opaque LSA (defined in [RFC4970] ). The SID/Label Range TLV MAY appear multiple times and has the following format: Liao, et al. Expires January 7, 2016 [Page 9] Internet-Draft SPRING SID Allocation July 2015 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +---------------------------------------------------------------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 OSPF SR Capabilities TLV o Type: TBD. o 1 octet of Length: variable, in bytes. o Range Size: 3 octets of the SID/label range. o Reserved: 1 octets, where the following extension are defined: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |A| | +-+-+-+-+-+-+-+-+ where: o A-Flag: Allocation flag. If set, then the router is capable of allocating SID capability. Sub-TLVs: Initially, the only supported Sub-TLV is the SID/Label TLV as defined in [I-D.ietf-ospf-segment-routing-extensions]. 7. Security Considerations TBD. 8. Acknowledgements In progress. Liao, et al. Expires January 7, 2016 [Page 10] Internet-Draft SPRING SID Allocation July 2015 9. IANA Considerations TBD. 10. Normative References [I-D.ietf-isis-segment-routing-extensions] Previdi, S., 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-05 (work in progress), June 2015. [I-D.ietf-ospf-prefix-link-attr] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", draft-ietf-ospf-prefix-link-attr-06 (work in progress), June 2015. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-05 (work in progress), June 2015. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-03 (work in progress), May 2015. [I-D.kh-spring-ip-ran-use-case] Khasnabish, B., hu, f., and L. Contreras, "Segment Routing in IP RAN use case", draft-kh-spring-ip-ran-use-case-02 (work in progress), November 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. Liao, et al. Expires January 7, 2016 [Page 11] Internet-Draft SPRING SID Allocation July 2015 Authors' Addresses Ting Liao ZTE Corporation No.50 Software Avenue Nanjing, Jiangsu 210012 China Phone: +86 25 88018801 Email: liao.ting@zte.com.cn Bo Wu ZTE Corporation No.50 Software Avenue Nanjing, Jiangsu 210012 China Phone: +86 25 88018801 Email: bo.wu@zte.com.cn Fangwei Hu ZTE Corporation No.889 Bibo Rd Shanghai 201203 China Phone: +86 21 68896273 Email: hu.fangwei@zte.com.cn Bhumip Khasnabish ZTE TX Inc. 55 Madison Avenue, Suite 160 Morristown, New Jersey 07960 USA Phone: +001-781-752-8003 Email: bhumip.khasnabish@ztetx.com Liao, et al. Expires January 7, 2016 [Page 12]