| PCE | Quan Xiong |
| Internet-Draft | Greg Mirsky |
| Intended status: Standards Track | ZTE Corporation |
| Expires: April 25, 2020 | Fangwei Hu |
| Individual | |
| Weiqiang Cheng | |
| China Mobile | |
| October 23, 2019 |
Stitching LSP Association
draft-hu-pce-stitching-lsp-association-02
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. [I-D.ietf-pce-association-group] proposed an association mechanism for a set of LSPs.
This document defines the stitching LSP association type and stitching LSP association TLV for the inter-domain scenairo.
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, 2020.
Copyright (c) 2019 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 (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.
[RFC5440] describes the Path Computation Element Protocol (PCEP) which is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP). [I-D.ietf-pce-association-group] proposed an association mechanism to create a grouping of LSPs in the context of a PCE.
[I-D.xiong-pce-stateful-pce-sr-inter-domain] introduces the procedure and the PCEP extension to form the inter-domain MPLS data entries and the multiple LSPs from multiple contiguous domains need to be stitched to an end-to-end LSP in SR inter-domain scenario.
This document proposes a new association object type called "stitching Association LSP type" and TLV called "Stitching LSP Association TLV" to associate a grouping of LSPs from multiple domains for inter-domain scenario.
The terminology is defined as [RFC5440], [I-D.ietf-pce-association-group] and [I-D.xiong-pce-stateful-pce-sr-inter-domain].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
As described in [I-D.xiong-pce-stateful-pce-sr-inter-domain], the domains of the networks may be IGP Areas in stitching inter-domain scenario. As Figure 1 shown, the multiple SR-MPLS domains may be interconnect with a ABR within areas. The multiple LSPs in each domain can be stitched to an inter-domain end-to-end LSP. The LSP-1, LSP-2 and LSP-3 can be associated to a group.
.................. ................. ....................
. . . . . .
+-----+ +-----+ +-----+ +-----+
| A | | X | | Y | | Z |
+-----+ +-----+ +-----+ +-----+
. IGP-1 . . IGP-2 . . IGP-3 .
.................. ................. ...................
|--------LSP-1------>|-------LSP-2------->|-------LSP-3------->|
|--------------Stitching LSP Association Group---------------->|
Figure 1: Stitching LSPs in SR-MPLS Inter-domain Scenario
The LSP Object is defined in Section 7.3 of [RFC8231]. This document defiend a new flag (I-flag) for the LSP Object as Figure 2 shown:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flag|I|C| O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: I-flag in LSP Object
I (Request for Inter-domain Path) : If the bit is set to 1, it indicates that the PCC requests PCE to compute the end-to-end path for inter-domain scenario carried in PCReq message. A parent PCE would set this bit to 1 to indicate that it is an end-to-end inter-domain path and a chid PCE would set it to 1 to indicate that the path is part of an end-to-end inter-domain path. That may be encoded in the PCRep, PCUpd or PCInitiate message.
An association ID will be used to identify the group and a new Association Type is defined in this document, based on the generic Association object :
Association Type (TBD) = Stitching LSP Association Group (SLAG).
SLAG may carry optional TLVs including but not limited to :
STITCHING-LSP-ASSOCIATION-TLV: Used to identify the role of stitching LSPs, described in Section 4.3.
As [I-D.ietf-pce-association-group] specified, the capability advertisement of the association types supported by a PCEP speaker is performed by defining a ASSOC-Type-List TLV to be carried within an OPEN object. The association type which defined in this document should be added in the list and be advertised between the PCEP speakers before the stitching LSP association.
Stitching LSP Association could be created dynamically or configured by the operator when operator-configured association is needed.
The format of the Stitching LSP Association TLV is shown in Figure 3.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|T|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Stitching LSP Association TLV
The fields of the Stitching LSP Association TLV are following:
Type:16 bits, it indicates the stitching LSP Association Group
TLV: TBD2, the value is assigned by IANA).
Length: the value is 4, it indicates the length of the TLV is 4 bytes.
Reserved: it is reserved for future use.
Stitching LSP Association Flags-S:1bit, indicates stitching LSP of the source domain when it is set.
Stitching LSP Association Flags-T:1bit, indicates stitching LSP of the transit domain when it is set.
Stitching LSP Association Flags-D:1bit, indicates stitching LSP of the destination layer when it is set.
TBA
TBA
[RFC8231] defines the LSP object; per that RFC, IANA created a registry to manage the value of the LSP object's Flag field. IANA is requested to make allocations from the registry, as follows:
| Value | Name | Reference |
|---|---|---|
| TBD | Request for Inter-domain Path (I) | [this document] |
This document defines a new association type and TLV in Association object which originally defined in [I-D.ietf-pce-association-group]. IANA is requested to make allocations from the registry, as follows:
| Value | Name | Reference |
|---|---|---|
| TBD | Stitching LSP Association Type | [this document] |
| TBD | Stitching LSP Association TLV | [this document] |