Networking Working Group Ran. Chen
Internet-Draft Zheng. Zhang
Intended status: Standards Track ZTE Corporation
Expires: September 23, 2019 March 22, 2019
PCEP Extensions for BIER
draft-chen-pce-bier-05
Abstract
Bit Index Explicit Replication (BIER)-TE shares architecture and
packet formats with BIER as described in [RFC8279]. BIER-TE forwards
and replicates packets based on a BitString in the packet header, but
every BitPosition of the BitString of a BIER-TE packet indicates one
or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE
Path can be derived from a Path Computation Element (PCE).
This document specifies extensions to the Path Computation Element
Protocol (PCEP) that allow a PCE to compute and initiate the path for
the BIER-TE.
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 September 23, 2019.
Copyright Notice
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
Chen & Zhang Expires September 23, 2019 [Page 1]
Internet-Draft PCEP Ext for BIER March 2019
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 used in this document . . . . . . . . . . . . . . 3
3. Overview of PCEP Operation in BIER Networks . . . . . . . . . 3
4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 3
4.1.1. The BIER-TE PCE Capability sub-TLV . . . . . . . . . 3
4.2. The SRP Object . . . . . . . . . . . . . . . . . . . . . 4
4.3. END-POINTS object . . . . . . . . . . . . . . . . . . . . 4
4.3.1. P2MP END-POINTS object . . . . . . . . . . . . . . . 4
4.3.2. The New BIER END-POINT Object . . . . . . . . . . . . 4
4.4. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 5
4.4.1. BIER-ERO Subobject . . . . . . . . . . . . . . . . . 6
4.4.2. BIER-ERO Processing . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 7
6.1.1. BIER-TE-PCE-CAPABILITY Sub-TLV Type Indicators . . . 7
6.1.2. New Path Setup Type . . . . . . . . . . . . . . . . . 8
6.1.3. New BIER END-POINT Object . . . . . . . . . . . . . . 8
6.1.4. BIER-ERO Subobject . . . . . . . . . . . . . . . . . 8
6.1.5. PCEP-Error Objects and Types . . . . . . . . . . . . 8
7. Normative references . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Bit Index Explicit Replication (BIER)-TE shares architecture and
packet formats with BIER as described in [RFC8279]. BIER-TE forwards
and replicates packets based on a BitString in the packet header, but
every BitPosition of the BitString of a BIER-TE packet indicates one
or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE
Path can be derived from a Path Computation Element (PCE).
[RFC8231] specifies a set of extensions to PCEP that allow a PCE to
compute and recommend network paths in compliance with [RFC4657] and
defines objects and TLVs for MPLS-TE LSPs.
This document uses a PCE for computing one or more BIER-TE paths
taking into account various constraints and objective functions.
Chen & Zhang Expires September 23, 2019 [Page 2]
Internet-Draft PCEP Ext for BIER March 2019
2. 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.
3. Overview of PCEP Operation in BIER Networks
BIER-TE forwards and replicates packets based on a BitString in the
packet header, and every BitPosition of the BitString of a BIER-TE
packet indicates one or more adjacencies as described in
[I-D.ietf-bier-te-arch]. In a PCEP session, An ERO object specified
in [RFC5440] can be extended to carry a BIER-TE path consists of one
or more BIER-ERO subobject(s). BIER-TE computed by a PCE can be
represented in the following forms:
o An ordered set of adjacencies BitString(s) in which each bit
represents that the adjacencies to which the BFR should replicate
packets to in the domain.
In this document, we define a set of PCEP protocol extensions,
including a new PCEP capability,a new Path Setup Type (PST) ,a new
BIER END-POINT Object, new ERO subobjects, new PCEP error codes and
procedures.
4. Object Formats
4.1. The OPEN Object
4.1.1. The BIER-TE PCE Capability sub-TLV
[RFC8408]defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the
OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional
list of sub-TLVs which are intended to convey parameters that are
associated with the path setup types supported by a PCEP speaker.
This document defines a new Path Setup Type (PST) for BIER as
follows:
o PST = TBD2: Path is setup using BIER Traffic Engineering
technique.
A PCEP speaker SHOULD indicate its support of the function described
in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
OPEN object with this new PST included in the PST list.
This document also defines the BIER-TE-PCE-CAPABILITY sub-TLV. PCEP
speakers use this sub-TLV to exchange BIER capability. If a PCEP
Chen & Zhang Expires September 23, 2019 [Page 3]
Internet-Draft PCEP Ext for BIER March 2019
speaker includes PST=TBD1 in the PST List of the PATH-SETUP-TYPE-
CAPABILITY TLV then it MUST also include the BIER-TE-PCE- CAPABILITY
sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV.
The format of the BIER-TE-PCE-CAPABILITY sub-TLV is shown in the
following figure:
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=TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The code point for the TLV type is to be defined by IANA.
Length: 4 bytes.
The "Reserved" (2 octet) and "Flags" (2 octet) fields are currently
unused, and MUST be set to zero on transmission and ignored on
reception.
4.2. The SRP Object
In order to setup an BIER-TE, a new PATH-SETUP-TYPE TLV MUST be
contained in RP/SRP object. This document defines a new Path Setup
Type (PST=TBD2) for BIER-TE.
4.3. END-POINTS object
4.3.1. P2MP END-POINTS object
The END-POINTS object which is defined in [RFC8306]is used in a PCReq
message to specify the BIER information of the path for which a path
computation is requested. To represent the end points for a BIER
path efficiently, we reuse the P2MP END-POINTS object body for
IPv4(Object-Type 3) and END-POINTS object body for IPv6 (Object-Type
4) which is defined in [RFC8306].
4.3.2. The New BIER END-POINT Object
In the case of BIER and BIER-TE coexistence scenario, we reuse the
BFR-id where is assigned
Chen & Zhang Expires September 23, 2019 [Page 4]
Internet-Draft PCEP Ext for BIER March 2019
For each sub-domain to which a given BFR belongs, if the BFR is
capable of acting as a BFIR or a BFER, it MUST be provisioned with a
"BFR-id" that is unique within the sub-domain which is defined in
[RFC8279], so in this scenario, we define a new BIER END-POINT
Object.It is optional.
The format of the new END-POINTS Object for BFR-id 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source BFR-id | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination BFR-id ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ Destination BFR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
leaf type: It is the same with the type which is defined in
[RFC8306].
Source BFR-id:A 2 octet field encoding the source BFR-id, A BFR-id is
just a number in the range [1,65535], identifies a BFIR uniquely in a
BIER subdomain.If no BFR-id has been assigned, the value of this
field is set to "Invalid BFR-id", which is defined as illegal in
[RFC8279].
Destniation BFR-id:A 2 octet field encoding the destniation BFR-id.A
BFR-id is just a number in the range [1,65535], identifies a BFER
uniquely.If no BFR-id has been assigned, the value of this field is
set to "Invalid BFR-id", which is defined as illegal in [RFC8279].
4.4. ERO Object
BIER-TE consists of one or more adjacencies BitStrings where every
BitPosition of the BitString indicates one or more adjacencies, as
described in([RFC8279]).
The ERO object specified in [RFC5440] is used to encode the path of a
TE LSP through the network.The ERO is carried within a PCRep message
to provide the computed TE LSP if the path computation was
Chen & Zhang Expires September 23, 2019 [Page 5]
Internet-Draft PCEP Ext for BIER March 2019
successful.In order to carry BIER-TE explicit paths, this document
defines a new ERO subobjects referred to as "BIER-ERO subobjects"
whose formats are specified in the following section. An BIER-ERO
subobjects carrying a adjacencies BitStrings consists of one or more
BIER-ERO subobject(s).
4.4.1. BIER-ERO Subobject
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=TBD4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BS Length | subdomain-id | SI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacency BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Adjacency BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
The 'L' Flag: Indicates whether the subobject represents a loose-hop
in the LSP[RFC3209]. If the bit is not set, the subobject represents
a strict hop in the explicit route.
Type: TBD4
Length: 1 octet ([RFC3209]). Contains the total length of the
subobject in octets. The Length MUST be at least 8, and MUST be a
multiple of 4.
BS Length: A 1 octet field encodes the length in bits of the
BitString as per [RFC8296], the maximum length of the BitString is 5,
it indicates the length of BitString is 1024.It is used to refer to
the number of bits in the BitString.
subdomain-id: Unique value identifying the BIER subdomain. 1 octet.
SI: Set Identifier (Section 1 of [RFC8279] used in the encapsulation
for this BIER subdomain for this BitString length, 1 octet.
Chen & Zhang Expires September 23, 2019 [Page 6]
Internet-Draft PCEP Ext for BIER March 2019
The "Reserved" (1 octets) fields are currently unused, and MUST be
set to zero on transmission and ignored on reception.
Adjacency BitString: a variable length field encoding the Adjacency
BitString where every BitPosition of the BitString indicates one or
more adjacencies.the length of this field is according the BS length.
The minimum value of this field is 64 bits, and the maximum value of
this field is 1024 bits.
Notice:
The maximum value of BS Length is limited to the 1024 bits, in case
the BIER-ERO Subobject is too long.
4.4.2. BIER-ERO Processing
The ERO and SR-ERO subobject processing remains as per [RFC5440].
If a PCC receives an BIER-ERO subobject in which either
BitStringLength or Adjacency BitString or SI is absent, it MUST
consider the entire BIER-ERO subobject invalid and send a PCErr
message with Error-Type = 10 ("Reception of an invalid object"),
Error-Value = TBD5 ("BitStringLength is absent ") or Error-Value =
TBD6 ("Adjacency BitString is absent")or Error-Value = TBD7("SI is
absent ").
If a PCC receives an BIER-ERO subobject in which BitStringLength
values are not chosen from: 64, 128, 256, 512, 1024, as it described
in ( [RFC8279]). The PCC MUST send a PCErr message with Error-Type
=10 ("Reception of an invalid object") and Error-Value = TBD8
("Invalid BitStringLength").
5. Security Considerations
TBD.
6. IANA Considerations
6.1. PCEP Objects
IANA has made the following Object-Type allocations from the "PCEP
Objects" sub-registry.
6.1.1. BIER-TE-PCE-CAPABILITY Sub-TLV Type Indicators
Chen & Zhang Expires September 23, 2019 [Page 7]
Internet-Draft PCEP Ext for BIER March 2019
vlaue Meaning Reference
-------------- ----------------------- -------------
TBD1 BIER-TE-PCE-CAPABILITY This Document
6.1.2. New Path Setup Type
vlaue Meaning Reference
-------------- ----------------------- -------------
TBD2 Path is setup using BIER
Traffic Engineering technique This Document
6.1.3. New BIER END-POINT Object
vlaue Meaning Reference
-------------- ----------------------- -------------
TBD3 END-POINTS Object for BFR-id This Document
6.1.4. BIER-ERO Subobject
This document defines a new subobject type for the BIER explicit
route object (ERO),The code points for subobject types of these
objects is maintained in the RSVP parameters registry.
Object Sub-Object Sub-Object Type
----------------- ----------------------- -----------------
EXPLICIT_ROUTE BIER-ERO (PCEP-specific) TBD4
6.1.5. PCEP-Error Objects and Types
IANA is requested to allocate code-points in the "PCEP-ERROR Object
Error Types and Values" subregistry for the following new error-types
and error-values:
Chen & Zhang Expires September 23, 2019 [Page 8]
Internet-Draft PCEP Ext for BIER March 2019
Error-Type Meaning Reference
--------- --------------------------- ----------------
10 Reception of an invalid object RFC5440
Error-value = TBD5 This document
BitStringLength is absent
Error-value = TBD6 This document
Adjacency BitString is absent
Error-value = TBD7 This document
SI is absent
Error-value = TBD8 This document
Invalid BitStringLength
7. Normative references
[I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic
Engineering for Bit Index Explicit Replication (BIER-TE)",
draft-ietf-bier-te-arch-01 (work in progress), 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
Chen & Zhang Expires September 23, 2019 [Page 9]
Internet-Draft PCEP Ext for BIER March 2019
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/info/rfc8306>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
Authors' Addresses
Ran Chen
ZTE Corporation
No.50 Software Avenue,Yuhuatai District
Nanjing, Jiangsu Province 210012
China
Phone: +86 025 88014636
Email: chen.ran@zte.com.cn
Chen & Zhang Expires September 23, 2019 [Page 10]
Internet-Draft PCEP Ext for BIER March 2019
Zheng Zhang
ZTE Corporation
No.50 Software Avenue,Yuhuatai District
Nanjing, Jiangsu Province 210012
China
Email: zhang.zheng@zte.com.cn
Chen & Zhang Expires September 23, 2019 [Page 11]