Internet Engineering Task Force H. Chen Internet-Draft Huawei Technologies Intended status: Standards Track A. Liu Expires: September 19, 2016 Ericsson F. Xu Verizon M. Toy Comcast V. Liu China Mobile March 18, 2016 Extensions to PCEP for Distributing Label Cross Domains draft-chen-pce-label-x-domains-04.txt Abstract This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP). 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 September 19, 2016. Copyright Notice Copyright (c) 2016 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 Chen, et al. Expires September 19, 2016 [Page 1] Internet-Draft Label Cross Domains March 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 4. Label Distribution . . . . . . . . . . . . . . . . . . . . . . 4 4.1. An Exmaple . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 5 5.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 5 5.2. Label Object . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. LSP Tunnel Object . . . . . . . . . . . . . . . . . . . . 7 5.4. Request Message Extension . . . . . . . . . . . . . . . . 9 5.5. Reply Message Extension . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 10 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Chen, et al. Expires September 19, 2016 [Page 2] Internet-Draft Label Cross Domains March 2016 1. Introduction After a path crossing multiple domains is computed, an inter-domain Traffic Engineering (TE) Label Switched Path (LSP) tunnel may be set up along the path by a number of tunnel central controllers (TCCs). Each of the domains through which the path goes may be controlled by a tunnel central controller (TCC), which sets up the segment of the TE LSP tunnel in the domain. When the TCC sets up the segment of the TE LSP tunnel in its domain that is not a domain containing the tail end of the tunnel, it needs a label from a downstream domain, which is next to it along the path. This document specifies extensions to PCEP for distributing a label from a domain to its upstream domain along the path for the TE LSP tunnel crossing multiple domains. 2. Terminology ABR: Area Border Router. Routers used to connect two IGP areas (areas in OSPF or levels in IS-IS). ASBR: Autonomous System Border Router. Routers used to connect together ASes of the same or different service providers via one or more inter-AS links. Boundary Node (BN): a boundary node is either an ABR in the context of inter-area Traffic Engineering or an ASBR in the context of inter-AS Traffic Engineering. Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along a determined sequence of domains. Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains. Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. Inter-AS TE LSP: A TE LSP that crosses an AS boundary. LSP: Label Switched Path. LSR: Label Switching Router. PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element. An entity (component, application, or Chen, et al. Expires September 19, 2016 [Page 3] Internet-Draft Label Cross Domains March 2016 network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PCE(i) is a PCE with the scope of domain(i). TED: Traffic Engineering Database. This document uses terminologies defined in RFC5440. 3. Conventions Used in This Document 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. 4. Label Distribution The Label Distribution may be provided by the PCE-based path computation. A PCE responsible for a domain computes a path segment for the domain, which is from an entry boundary to an exit boundary (or an egress) node of the domain. The PCE gets an label from the entry boundary node and adds an label object containing the label in the reply message to be sent to the requesting PCC (or another PCE). When a PCE or PCC receives a reply message containing an label object, it removes the object from the message. The PCE may store the information in the label object or send the information to another component such as a Tunnel Central Controller (TCC). 4.1. An Exmaple Figure 1 below illustrates a simple two-AS topology. There is a PCE responsible for the path computation in each AS. A path computation is requested from the Tunnel Central Controller (TCC), acting as the PCC, which sends the path computation request to PCE-1. PCE-1 is unable to compute an end-to-end path and invokes PCE-2 (possibly using the techniques described in [RFC5441]). PCE-2 computes a path segment from entry boundary node ASBR-2 of the right domain to the egress as {ASBR-2, C, D, Egress}. In addition to placing this path segment in the reply message to PCE-1, PCE-2 gets an label from the entry boundary node ASBR-2 and adds an label object containing the label and optionally the ASBR-2 into the reply message. Chen, et al. Expires September 19, 2016 [Page 4] Internet-Draft Label Cross Domains March 2016 ------------------------------- ------------------------------ | ------- | | ------- | | +-->| PCE-1 |<---------+--+-->| PCE-2 | | | | ------- | | ------- | | v | | ^ | | ----- | | | | | | TCC | | | | | | | PCC | | | | | | ----- | | v | | ------- - - ------ | | ------ - - ------ | | |Ingress|--|A|--|B|--|ASBR-1|-+--+-|ASBR-2|--|C|--|D|--|Egress| | | ------- - - ------ | | ------ - - ------ | | | | | ------------------------------- ------------------------------ Figure 1: Example of Label Distribution When PCE-1 receives the reply message containing the label object from PCE-2, it removes the object from the message. PCE-1 may store the information in the label object or send the information to another component such as a Tunnel Central Controller (TCC). TCC may set up the segment of the LSP tunnel from Ingress to ASBR-2 using the label in the label object from ASBR-2. 5. Extensions to PCEP This section describes the extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP). The extensions include the definition of a new flag in the RP object, tunnel information and label in a PCReq/PCRep message. 5.1. RP Object Extension The following flags are added into the RP Object: o L (Label distribution bit - 1 bit): 0: This indicates that this is not a PCReq/PCRep message for distributing labels crossing domains. 1: This indicates that this is a PCReq or PCRep message for distributing labels crossing domains. Chen, et al. Expires September 19, 2016 [Page 5] Internet-Draft Label Cross Domains March 2016 o C (LSP tunnel Creation bit - 1 bit): 0: This indicates that this is not a PCReq/PCRep message for creating the segment of the LSP tunnel. 1: This indicates that this is a PCReq/PCRep message for creating the segment of the LSP tunnel in the domain before distributing labels to its previous domain. An L bit is added in the flag bits field of the RP object to tell a receiver of a PCReq/PCRep message that the message is for distributing labels crossing domains for an inter-domain LSP. The IANA request is referenced in Section below (Request Parameter Bit Flags) of this document. The C bit is added in the flag bits field of the RP object to tell the receiver of a PCReq/PCRep message that the message is for creating the segment of the LSP tunnel in a domain before distributing labels from this domain to its previous domain. The IANA request is referenced in Section below (Request Parameter Bit Flags) of this document. This L bit with the N bit defined in RFC6006 can indicate whether the PCReq/PCRep message is for distributing labels for an MPLS TE P2P LSP or an MPLS TE P2MP LSP. o L = 1 and N = 0: This indicates that this is a PCReq/PCRep message for distributing labels for a P2P LSP. o L = 1 and N = 1: This indicates that this is a PCReq/PCRep message for distributing labels for a P2MP LSP. 5.2. Label Object The format of a label object body (Object-Type=2) is illustrated below, which comprises a label and an optional node sub object. The node sub object contains a boundary node IP address, from which the label is allocated and distributed. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node IPv4/IPv6 sub object (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chen, et al. Expires September 19, 2016 [Page 6] Internet-Draft Label Cross Domains March 2016 The format of the node IPv4 address sub object (Type=1) is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type(1) | Length (8) | Node IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node IPv4 address (cont) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the node IPv6 address sub object (Type=2) is illustrated below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type(2) | Length (20) | Node IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Node IPv6 address (cont) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node IPv6 address (cont) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. LSP Tunnel Object The LSP tunnel object contains the information that may be used to identify an LSP tunnel. An LSP tunnel may be a P2P or P2MP LSP tunnel. It may be an IPv4 or IPv6 LPS tunnel. Thus there are four types of LSP tunnels: 1) P2P LSP IPv4 tunnel, 2) P2P LSP IPv6 tunnel, 3) P2MP LSP IPv4 tunnel, and 4) P2MP LSP IPv6 tunnel. The format of the P2P LSP IPv4/6 tunnel object body is as follows: Chen, et al. Expires September 19, 2016 [Page 7] Internet-Draft Label Cross Domains March 2016 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2P LSP Tunnel Egress IPv4/6 Address (4/16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID (4/16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Controller ID (4/16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o P2P LSP Tunnel Egress IPv4/6 Address: IPv4/6 address of the egress of the tunnel. o Tunnel ID: A 16-bit identifier that is constant over the life of the tunnel. o Extended Tunnel ID: A 4/16-byte identifier that is constant over the life of the tunnel. o LSP ID: A 16-bit identifier to allow resources sharing. o Controller ID: A 4/16-byte identifier for the controller responsible for the head segment of the tunnel. The format of the P2MP LSP IPv4/6 tunnel object body is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID (4/16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Controller ID (4/16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chen, et al. Expires September 19, 2016 [Page 8] Internet-Draft Label Cross Domains March 2016 o P2MP ID: A 32-bit number unique within the ingress of LSP tunnel. o Tunnel ID: A 16-bit identifier that is constant over the life of the tunnel. o Extended Tunnel ID: A 4/16-byte identifier that is constant over the life of the tunnel. o LSP ID: A 16-bit identifier to allow resources sharing. o Controller ID: A 16-byte identifier for the controller responsible for the head segment of the tunnel. 5.4. Request Message Extension Figure below illustrates the format of a request message with a optional LSP tunnel object: ::= [] ::=[] ::= [] [] [] [] [[]] [] [] [] 5.5. Reply Message Extension Below is the format of a reply message with an optional Label object: ::= ::=[] ::= [] [] [] ::=[] ::= [][