PCE Working Group Y. Wang
Internet-Draft A. Wang
Intended status: Standards Track China Telecom
Expires: June 24, 2022 December 21, 2021
PCEP Procedures and Extension for VLAN-based Traffic Forwarding
draft-wang-pce-vlan-based-traffic-forwarding-02
Abstract
This document defines the Path Computation Element Communication
Protocol (PCEP) extension for VLAN-based traffic forwarding in native
IP network and describes the essential elements and key processes of
the data packet forwarding system based on VLAN info to accomplish
the End to End (E2E) traffic assurance for VLAN-based traffic
forwarding in native IP network.
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 June 24, 2022.
Copyright Notice
Copyright (c) 2021 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
Wang & Wang Expires June 24, 2022 [Page 1]
Internet-Draft pce December 2021
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Procedures for VLAN-based Traffic Forwarding . . . . . . . . 4
5. Capability Advertisement . . . . . . . . . . . . . . . . . . 4
6. PCEP message . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 6
6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 7
7. VXLAN-based traffic forwarding Procedures . . . . . . . . . . 8
7.1. Multiple BGP Session Establishment Procedures . . . . . . 8
7.2. BGP Prefix Advertisement Procedures . . . . . . . . . . . 8
7.3. VLAN mapping info Advertisement Procedures . . . . . . . 9
7.3.1. VLAN-Based forwarding info Advertisement Procedures . 9
7.3.2. VLAN-Based crossing info Advertisement Procedures . . 11
8. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 13
8.1. VLAN forwarding CCI Object . . . . . . . . . . . . . . . 13
8.2. Address TLVs . . . . . . . . . . . . . . . . . . . . . . 15
8.3. VLAN crossing CCI Object . . . . . . . . . . . . . . . . 15
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 16
11.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 17
11.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 17
11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
13. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
[RFC8283] introduces the architecture for the PCE as a central
controller as an extension to the architecture described in
[RFC4655]. Based on such mechanism, the PCE can calculate the
optimal path for vairous applications and send the intructions to the
network equipment via PCEP protocol, thus control the packet
forwarding and achive the QoS assurance effects for priority traffic.
[RFC8735] describes the scenarios of QoS assurance for hybrid cloud-
based application within one domain and traffic engineering in multi-
domain. It proposes also the consideration for the potential
solution, that is:
Wang & Wang Expires June 24, 2022 [Page 2]
Internet-Draft pce December 2021
1. Should be applied both in native IPv4 and IPv6 environment.
2. Should be same procedures for the intra-domain and itner-domain
scenario.
3. Should utilize the existing forwarding capabiliites of the
deployed network devices.
With the large scale deployment of Ethernet interfaces in operator
network and PCECC architecture, it is possilbe to utilize the VLAN
information within the ethernet header to build one end-to-end
dedicated path to guide the forwarding of the packet. Similar with
the PCECC for LSP [RFC9050], this document defines a Path Computation
Element Communication Protocol (PCEP) Extension for VLAN-based
traffic forwarding by using the VLAN info contained in the Ethernet
frame in native IP network and the mechanism is actually the PCECC
for VSP(VLAN Switched Path). It is an end to end traffic guarantee
mechanism based on the PCEP protocol in the native IP environment,
which can ensure the connection-oriented network communication. It
can simplifiy the calculation and forwarding process of the optimal
path by blending it with elements of PCEP and without necessarily
completely replacing it.
Compared with other traffic assurance technologies such as mpls or
srv6 which is supported only in IPv6 environment, and has the obvious
packet overhead problems, the VLAN-based traffic forwarding (VTF)
mechanism uses a completely new address space which will not conflict
with other existing protocols and can easily avoid these problems and
be deployed in IPv4 and IPv6 environment simultaneously. It is
suitable for ipv4 and ipv6 networks and can leverage the existing PCE
technologies as much as possible.
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. Terminology
The following terms are defined in this draft:
o PCC: Path Computation Client
o PCE: Path Computation Element
o PCEP: PCE Communication Protocol
Wang & Wang Expires June 24, 2022 [Page 3]
Internet-Draft pce December 2021
o PCECC: PCE-based Central Controller
o LSP: Lable Switching Path
o PST: Path Setup Type
4. Procedures for VLAN-based Traffic Forwarding
The target deployment environment of VLANbased traffic forwarding
mechanism is for Native IP(IPv4 and IPv6). In such scenarios, the
BGP is used for the prefix distribution among underlying
devices(PCCs), no MPLS is involved. In order to set up the VLAN-
based traffic forwarding paths for different applications in native
IP network, multiple BGP sessions should be deployed between the
ingress PCC and egress PCC at the edge of the network respectively.
Based on the business requirements, the PCE calculates the explict
route and sends the route information to the PCCs through PCInitiate
messages. When received the PCInitiate message, the ingress PCC will
form a VLAN-Forwarding routing table defined in this document. The
packet to be guaranteed will be matched in the table and then be
labeled with corresponding VLAN tag. The labeled packet will be
further sent to the PCC's specific subinterface identified by the
VLAN tag and then be forwarded. Similarly, the transit PCC and the
egress PCC will form a VLAN-Crossing routing table after received the
PCInitiate message. The packet to be guaranteed will be relabled
with new VLAN tag and then be forwarded. The whole procedures mainly
forcus on the end-to-end traffic for key application which can ensure
the adequacy of VLAN number for this scenario. During the whole
packet forwarding process, the packet can be encapsulated with
reserved multicast MAC addresses(e.g. 0180:C200:0014 for ISIS levle1,
0180:C200:0015 for ISIS levle2) and don't need to change hop by hop
so as to accept by each PCC.
5. Capability Advertisement
During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support of VLAN-based trafficforwarding extensions.
This document defines a new Path Setup Type (PST)[RFC8408] for PCECC,
as follows:
o PST=TBD1: Path is a VLAN-based traffic forwarding type.
A PCEP speaker MUST 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.
Because the path is set up through PCE, a PCEP speaker must advertise
the PCECC capability by using PCECC-CAPABILITY sub-TLV which is used
Wang & Wang Expires June 24, 2022 [Page 4]
Internet-Draft pce December 2021
to exchange information about their PCECC capability as per PCEP
extensions defined in
[I-D.ietf-pce-pcep-extension-for-pce-controller]
A new flag is defined in PCECC-CAPABILITY sub-TLV for VLAN-based
traffic forwarding.
V (VLAN-based-forwarding-CAPABILITY - 1 bit - TBD2): If set to 1 by a
PCEP speaker, it indicates that the PCEP speaker supports the
capability of VLAN based traffic forwarding as specified in this
document. The flag MUST be set by both the PCC and PCE in order to
support this extension.
If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with
the newly defined path setup type, but without the V bit set in
PCECC-CAPABILITY sub-TLV, it MUST:
o Send a PCErr message with Error-Type=10(Reception of an invalid
object) and Error-Value TBD3(PCECC VLAN-based-forwarding-
CAPABILITY bit is not set).
o Terminate the PCEP session
6. PCEP message
As per [RFC8281] ,the PCInitiate message sent by a PCE was defined to
trigger LSP instantiation or deletion with the SRP and LSP object
included during the PCEP initialization phase. The Path Computation
LSP State Report message (PCRpt message) was defined in [RFC8231],
which is used to report the current state of a LSP. A PCC can send a
LSP State Report message in response to a LSP instantiation.
Besides, the message can either in response to a LSP Update Request
from a PCE or asynchronously when the state of a LSP changes .
[I-D.ietf-pce-pcep-extension-for-pce-controller] defines an object
called Central Controller Instructions (CCI) to specify the
forwarding instructions to the PCC. During the coding process used
for central controller instructions, the object contains the label
information and is carried within PCInitiate or PCRpt message for
label download .
This document specify two new CCI object-types for VLAN-based traffic
forwarding in the native IP network and are said to be mandatory in a
PCEP message when the object must be included for the message to be
considered valid. In addition, this document enxtends the PCEP
message to handle the VLAN-based traffic forwarding path in the
native IP network with the new CCI object.
Wang & Wang Expires June 24, 2022 [Page 5]
Internet-Draft pce December 2021
6.1. The PCInitiate message
The PCInitiate message[RFC8281] extended
in[I-D.ietf-pce-pcep-extension-for-pce-controller] can be used to
download or remove labels by using the CCI Object.
Based on the extended PCInitiate message and PCRpt described in
[I-D.ietf-pce-pcep-extension-native-ip], the (BGP Peer Info (BPI)
Object and the Peer Prefix Association (PPA) Object is used to
establish multi BGP sessions and advertise route prefixes among
different BGP sessions before setting up a VLAN-based traffic
forwarding path.
This document extends the PCInitiate message as shown below:
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<Common Header> is defined in [RFC5440]
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>|
<PCE-initiated-lsp-central-control>)
<PCE-initiated-lsp-central-control> ::= <SRP>
<LSP>
<cci-list>|
((<BPI>|<PPA>)
<new-CCI>)
<cci-list> ::= <new-CCI>
[<cci-list>]
Where:
<cci-list> is as per
[I-D.ietf-pce-pcep-extension-for-pce-controller].
<PCE-initiated-lsp-instantiation> and
<PCE-initiated-lsp-deletion> are as per [RFC8281].
<BPI> and <PPA> are as per
[draft-ietf-pce-pcep-extension-native-ip-09]
When PCInitiate message is used to create VLAN-based forwarding
instructions, the SRP, LSP and CCI objects MUST be present. The
error handling for missing SRP, LSP or CCI object is as per
Wang & Wang Expires June 24, 2022 [Page 6]
Internet-Draft pce December 2021
[I-D.ietf-pce-pcep-extension-for-pce-controller]. Further only one
of BPI, PPA or one type of CCI objects MUST be present. If none of
them are present, the receiving PCE MUST send a PCErr message with
Error- type=6 (Mandatory Object missing) and Error-value=TBD4 ( VLAN-
based forwarding object missing). If there are more than one of BPI,
PPA or one type of CCI objects are presented, the receiving PCC MUST
send a PCErr message with Error-type=19(Invalid Operation) and Error-
value=TBD5(Only one of BPI, PPA or one type of the CCI objects for
VLAN can be included in this message).
6.2. The PCRpt message
The PCRpt message is used to report the state and confirm the VLAN
info that were allocated by the PCE, to be used during the state
synchronization phase or as acknowledgemnt to PCInitiate message.
The format of the PCRpt message is as follows:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= (<lsp-state-report>|
<central-control-report>)
<lsp-state-report> ::= [<SRP>]
<LSP>
<path>
<central-control-report> ::= [<SRP>]
<LSP>
<cci-list>|
((<BPI>|<PPA>)
(<new-CCI>)
Where:
<path> is as per [RFC8231] and the LSP and SRP object are
also defined in [RFC8231].
<BPI> and <PPA> are as per
[draft-ietf-pce-pcep-extension-native-ip-09]
The error handling for missing LSP or CCI object is as per
[I-D.ietf-pce-pcep-extension-for-pce-controller]. Further only one
of BPI, PPA or one type of CCI objects MUST be present. If none of
them are present, the receiving PCE MUST send a PCErr message with
Wang & Wang Expires June 24, 2022 [Page 7]
Internet-Draft pce December 2021
Error- type=6 (Mandatory Object missing) and Error-value=TBD4 ( VLAN-
based forwarding object missing). If there are more than one of BPI,
PPA or one type of CCI objects are presented, the receiving PCC MUST
send a PCErr message with Error-type=19(Invalid Operation) and Error-
value=TBD5(Only one of BPI, PPA or one type of the CCI objects for
VLAN can be included in this message).
7. VXLAN-based traffic forwarding Procedures
7.1. Multiple BGP Session Establishment Procedures
As described in section 4, multiple BGP sessions should be deployed
between the ingress device and egress device at the edge of the
network respectively in order to carry informations of different
applications. As per [I-D.ietf-pce-pcep-extension-native-ip], the
PCE should send the BPI((BGP Peer Info) Object to the ingress and
egress device with the indicated Peer AS and Local/Peer IP address.
The Ingress and egress devices will receive multiple BPI objects to
establish sessions with different next hop. The specific process is
as follows:
+----------------------+
+---------+- PCE + --------+
| +----------^-----------+ |
| | | | |
| +--+ +--+ +--+ |
|------- +R2+ ------+R3+-------+R4+ --------
| +--+ +--+ +--+ |
| |
+--+ +--+ +--+
+R1+----------------+R5+----------------+R6+
+--+ +--+ +--+
| |
|<------------- BGP Session A ------------>|
|<------------- BGP Session B ------------>|
|<------------- BGP Session C ------------>|
Figure 1: BGP Session Establishment Procedures
7.2. BGP Prefix Advertisement Procedures
The detail procedures for BGP prefix advertisement procedures is
introduced in [I-D.ietf-pce-pcep-extension-native-ip], using
PCInitiate and PCRpt message pair.
The BGP prefix for different BGP sessions should be sent to the
ingress and egress device respectively. The end-to-end traffic for
key application can be identified based on these BGP prefix
Wang & Wang Expires June 24, 2022 [Page 8]
Internet-Draft pce December 2021
informations and be further assured. As per
[I-D.ietf-pce-pcep-extension-native-ip], the PPA(Peer Prefix
Association) object with list of prefix subobjects and the peer
address will be sent through the PCInitiate and PCRpt message
pair.The specific process is as follows,:
+----------------------+
+---------+- PCE + --------+
| +----------^-----------+ |
| | | | |
| +--+ +--+ +--+ |
|------- +R2+ ------+R3+-------+R4+ --------
| +--+ +--+ +--+ |
| |
+--+ +--+ +--+
+R1+----------------+R5+----------------+R6+
+--+ +--+ +--+
Figure 2: BGP Prefix Advertisement Procedures
Through BGP protocol, the ingress device can learn different BGP
prefix of the egress device based on the different BGP sessions.
7.3. VLAN mapping info Advertisement Procedures
After the BGP prefix for different BGP session are successfully
advertised, informations of different applications should be
forwarded to different VLAN-based traffic forwarding paths. In order
to set up a VLAN-based traffic forwarding path, the PCE should send
the VLAN forwarding CCI Object with the VLAN-ID included to the
ingress PCC and the VLAN crossing CCI Object to the transit PCC and
egrss PCC.
7.3.1. VLAN-Based forwarding info Advertisement Procedures
The detail procedures for VLAN-Based forwarding info advertisement
contained in the VLAN forwarding CCI Object is shown below, using
PCInitiate and PCRpt message pair.
The VLAN forwarding CCI Object should be sent through the PCInitiate
and PCRpt message pair. After the PCC receives the CCI object (with
the R bit set to 0 in SRP object) in PCInitiate message, the PCC will
form a VLAN-Forwarding routing table and the PCC's subinterface will
set up the specific vlan based on the VLAN forwarding CCI object,
source and destination BGP prefix learnt before. When the ingress
PCC receives a packet, it will look up the VLAN-Forwarding routing
table based on the source and destination IP contained in the packet.
The packet to be guaranteed will be matched in the table and then be
Wang & Wang Expires June 24, 2022 [Page 9]
Internet-Draft pce December 2021
labeled with corresponding VLAN tag. After that, The labeled packet
will be further forwarded to the specific subinterface.
When the packet is tagged and successfully sent, the PCC should
report the result via the PCRpt messages, with VLAN forwarding CCI
Object and the corresponding SRP object included.
When PCC receives the VLAN forwarding CCI Object with the R bit set
to 1 in SRP object in PCInitiate message, the PCC should withdraw the
VLAN-Based forwarding info advertisement to the peer that indicated
by this object.
When PCC withdraws the VLAN-Based forwarding info that indicated by
this object successfully, it should report the result via the PCRpt
message, with the corresponding SRP and CCI object included.
+----------------------+
+---------+ PCE + --------+
| +----------^-----------+ |
| | | | |
M1&M1-R | | | |
| | | | |
| | | | |
| +--+ +--+ +--+ |
|------- +R2+ ------+R3+-------+R4+ --------
| +--+ +--+ +--+ |
| |
+--+ +--+ +--+
+R1+----------------+R5+----------------+R6+
+--+ +--+ +--+
Figure 3: VLAN-Based forwarding info Advertisement
Procedures for Ingress PCC
The message number, message peers, message type and message key
parameters in the above figures are shown in below table:
Table 1: Message Information
+-------------------------------------------------------------+
| No.| Peers| Type | Message Key Parameters |
+-------------------------------------------------------------+
|M1 |PCE/R1|PCInitiate|CC-ID=X1 |
|M1-R| |PCRpt |VLAN Forwarding CCI Object |
| | | |(Peer_IP=R6_A,Interface_Address=INF1, |
| | | |VLAN_ID=VLAN_R1_R2) |
+-------------------------------------------------------------+
Wang & Wang Expires June 24, 2022 [Page 10]
Internet-Draft pce December 2021
7.3.2. VLAN-Based crossing info Advertisement Procedures
The detail procedures for VLAN-Based crossing info advertisement
contained in the VLAN crossing CCI Object is shown below, using
PCInitiate and PCRpt message pair.
The PCC would receive VLAN crossing CCI Objects with the in-VLAN CCI
without the O bit set and the out-VLAN CCI with the O bit set. After
the process of VLAN-Based forwarding info advertisement mentioned
above, the PCC will form a VLAN-crossing routing table and the PCC's
subinterface will set up the specific vlan based on the VLAN crossing
CCI Object(with the R bit set to 0 in SRP object) contained in the
PCInitiate message. The VLAN-crossing routing table consists of an
in-VLAN tag and an out-VLAN tag which specifies a new VLAN forwarding
path. When the transit PCC receives a data packet that has been
labeled with VLAN by ingress PCC before, it will look up the VLAN-
Crossing routing table based on the VLAN tag. If matched, the in-
VLAN tag of this data packet will be replaced by a new out-VLAN tag
of the current transit PCC according to the table.The packet with the
new VLAN tag will be further forwarded to the next hop.
For the egress PCC, the out-VLAN tag in the VLAN-crossing routing
table should be 0 which indicates it is the last hop of the
transmission. So the egress PCC will directly remove the in-VLAN tag
of the packet and the packet will be forwarded.
When the packet is tagged and successfully sent to the specific
subinterface, the PCC should report the result via the PCRpt
messages, with the corresponding SRP and CCI object included.
When PCC receives the VLAN crossing CCI Object with the R bit set to
1 in SRP object in PCInitiate message, the PCC should withdraw the
VLAN-Based crossing info advertisement to the peer that indicated by
this object.
When PCC withdraws the VLAN-Based crossing info that indicated by
this object successfully, it should report the result via the PCRpt
message, with the corresponding SRP and CCI object included.
When the out-VLAN tag conflicts with a pre-defined VLAN tag or the
PCC can not set up a VLAN forwarding path with the out-VLAN tag, an
error (Error-type=TBD6, VLAN-based forwarding failure, Error-
value=TBD7, VLAN crossing CCI Object peer info mismatch) should be
reported via the PCRpt message.
Wang & Wang Expires June 24, 2022 [Page 11]
Internet-Draft pce December 2021
+----------------------+
+---------+ PCE + --------+
| +----------^-----------+ |
| | | | |
| M1&M1-R M2&M2-R M3&M3-R M4&M4-R
| | | | |
| +--+ +--+ +--+ |
|------- +R2+ ------+R3+-------+R4+ -------|
| +--+ +--+ +--+ |
| |
+--+ +--+ +--+
+R1+----------------+R5+----------------+R6+
+--+ +--+ +--+
Figure 4: VLAN-Based crossing info Advertisement Procedures
for transit PCC and egress PCC
The message number, message peers, message type and message key
parameters in the above figures are shown in below table:
Table 2: Message Information
+--------------------------------------------------------------------------+
| No.| Peers| Type | Message Key Parameters |
+--------------------------------------------------------------------------+
|M1 |PCE/R2|PCInitiate|CC-ID=X1 |
|M1-R| |PCRpt |VLAN crossing CCI Object(IN) |
| | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R1_R2) |
| | | |VLAN crossing CCI Object(OUT) |
| | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R2_R3)|
+--------------------------------------------------------------------------+
|M2 |PCE/R3|PCInitiate|CC-ID=X1 |
|M2-R| |PCRpt |VLAN crossing CCI Object(IN) |
| | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R2_R3) |
| | | |VLAN crossing CCI Object(OUT) |
| | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R3_R4)|
+--------------------------------------------------------------------------+
|M3 |PCE/R4|PCInitiate|CC-ID=X1 |
|M3-R| |PCRpt |VLAN crossing CCI Object(IN) |
| | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R3_R4) |
| | | |VLAN crossing CCI Object(OUT) |
| | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R4_R6)|
+--------------------------------------------------------------------------+
|M4 |PCE/R6|PCInitiate|CC-ID=X1 |
|M4-R| |PCRpt |VLAN crossing CCI Object(IN) |
| | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R4_R6) |
| | | |VLAN crossing CCI Object(OUT) |
| | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=0) |
+--------------------------------------------------------------------------+
Wang & Wang Expires June 24, 2022 [Page 12]
Internet-Draft pce December 2021
8. New PCEP Objects
The Central Control Instructions (CCI) Object is used by the PCE to
specify the forwarding instructions is defined in
[I-D.ietf-pce-pcep-extension-for-pce-controller]. This document
defines another two CCI object-types for VLAN-based traffic
forwarding network. All new PCEP objects are compliant with the PCEP
object format defined in [RFC5440].
8.1. VLAN forwarding CCI Object
The VLAN forwarding CCI Object is used to set up the specific vlan
forwarding path of the logical subinterface that the traffic will be
forwarded to and transfer the packet to the specific hop. Combined
with this type of CCI Object and the Peer Prefix Association
object(PPA) defined in [I-D.ietf-pce-pcep-extension-native-ip], the
ingress PCC will form a VLAN-Forwarding routing table which is used
to identify the traffic that needs to be protected. This object
should only be included and sent to the ingress PCC of the end2end
path.
CCI Object-Class is 44.
CCI Object-Type is TBD8 for VLAN forwarding info in the native IP
network.
Wang & Wang Expires June 24, 2022 [Page 13]
Internet-Draft pce December 2021
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Interface Address TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Peer IP Address TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Additional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: VLAN Forwarding CCI Object
The fields in the CCI object are as follows:
CC-ID: is as described in
[I-D.ietf-pce-pcep-extension-for-pce-controller]. Following fields
are defined for CCI Object-Type TBD8.
Reserved1(16 bits): is set to zero while sending, ignored on receipt.
Flags(16 bits): is used to carry any additional information
pertaining to the CCI. Currently no flag bits are defined.
VLAN ID(12 bits):the ID of the VLAN forwarding path that the PCC will
set up on its logical subinterface in order to transfer the packet to
the specific hop.
Reserved2(20 bits): is set to zero while sending, ignored on receipt.
Interface Address TLV [RFC8779] MUST be included in this CCI Object-
Type TBD8 to specify the interface which will set up the vlan defined
in the VLAN Forwarding CCI Object.
The Peer IP Address TLV[RFC8779]MUST be included in this CCI Object-
Type TBD8 to identify the end to end TE path in VLAN-based traffic
forwarding network and MUST be unique.
Wang & Wang Expires June 24, 2022 [Page 14]
Internet-Draft pce December 2021
8.2. Address TLVs
[RFC8779] defines IPV4-ADDRESS, IPV6-ADDRESS, and UNNUMBERED-ENDPOINT
TLVs for the use of Generalized Endpoint. The same TLVs can also be
used in the CCI object to find the Peer address that matches egress
PCC and further identify the packet to be guaranteed. If the PCC is
not able to resolve the peer information or can not find the
corresponding ingress device, it MUST reject the CCI and respond with
a PCErr message with Error-Type = TBD6 ("VLAN-based forwarding
failure") and Error Value = TBD9 ("Invalid egress PCC information").
8.3. VLAN crossing CCI Object
The VLAN crossing CCI object is defined to control the transmission-
path of the packet by VLAN-ID.This new type of CCI Object can be
carried within a PCInitiate message sent by the PCE to the transit
PCC and the egress PCC in the VLAN-based traffic forwarding
scenarios.
CCI Object-Class is 44.
CCI Object-Type is TBD10 for VLAN crossing info in the native IP
network.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Flags |O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN-VLAN-ID | OUT-VLAN-ID | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Interface Address TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Additional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: VLAN Crossing CCI Object
CC-ID: is as described in
[I-D.ietf-pce-pcep-extension-for-pce-controller]. Following fields
are defined for CCI Object-Type TBD10.
Wang & Wang Expires June 24, 2022 [Page 15]
Internet-Draft pce December 2021
Reserved1(16 bits): is set to zero while sending, ignored on receipt.
Flags(16 bits): is used to carry any additional information
pertaining to the CCI.Currently, the following flag bit are defined:
* O bit (out-label) : If the bit is set to '1', it specifies the VLAN
is the out-VLAN, and it is mandatory to encode the egress interface
information(via Interface Address TLVs in the CCI object). If the
bit is not set or set to '0', it specifies the VLAN is the in-VLAN,
and it is mandatory to encode the ingress interface information.
IN-VLAN ID(12 bits): The ID of the VLAN forwarding path which is used
to identify the traffic that needs to be protected.
OUT-VLAN ID(12 bits):The ID of the VLAN forwarding path that the PCC
will set up on its logical subinterface in order to transfer the
packet labeld with this VLAN ID to the specific hop.To the transit
PCC, the value must not be 0 to indicate it is not the last hop of
the VLAN-based traffic forwarding path. To the egress PCC, the value
must be 0 to indicate it is the last hop of the VLAN-based traffic
forwarding path.
Reserved2(8 bits): is set to zero while sending, ignored on receipt.
Interface Address TLV [RFC8779] MUST be included in this CCI Object-
Type TBD8 to specify the interface which will set up the vlan defined
in the VLAN Forwarding CCI Object.
9. Deployment Considerations
10. Security Considerations
11. IANA Considerations
11.1. Path Setup Type Registry
[RFC8408] created a sub-registry within the "Path Computation Element
Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
IANA is requested to allocate a new code point within this registry,
as follows:
Value Description Reference
TBD1 VLAN-Based Traffic Forwarding Path This document
Wang & Wang Expires June 24, 2022 [Page 16]
Internet-Draft pce December 2021
11.2. PCECC-CAPABILITY sub-TLV's Flag field
[I-D.ietf-pce-pcep-extension-for-pce-controller] created a sub-
registry within the "Path Computation Element Protocol (PCEP)
Numbers" registry to manage the value of the PCECC-CAPABILITY sub-
TLV's 32-bits Flag field. IANA is requested to allocate a new bit
position within this registry, as follows:
Value Description Reference
TBD2(V) VLAN-Based Forwarding CAPABILITY This document
11.3. PCEP Object Types
IANA is requested to allocate new registry for the PCEP Object Type:
Object-Class Value Name Reference
44 CCI Object-Type This document
TBD8: VLAN forwarding CCI
TBD10: VLAN crossing CCI
11.4. PCEP-Error Object
IANA is requested to allocate new error types and error values within
the "PCEP-ERROR Object Error Types and Values" sub-registry of the
PCEP Numbers registry for the following errors:
Error-Type Meaning Error-value Reference
6 Mandatory Object missing TBD4:VLAN-based This document
forwarding object
missing
10 Reception of an TBD3:PCECC This document
invalid object VLAN-based-forwarding
-CAPABILITY
bit is not set
19 Invalid Operation TBD5: Only one of BPI, This document
PPA or one type of
the CCI objects
for VLAN can be included
in this message
TBD6 VLAN-based forwarding TBD7: VLAN crossing CCI This document
failure Object peer info mismatch
TBD9: Invalid egress This document
PCC information
Wang & Wang Expires June 24, 2022 [Page 17]
Internet-Draft pce December 2021
12. Acknowledgement
13. Normative References
[I-D.ietf-pce-pcep-extension-for-pce-controller]
Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou,
"Path Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-14 (work in progress), March
2021.
[I-D.ietf-pce-pcep-extension-native-ip]
Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu,
"PCEP Extension for Native IP Network", draft-ietf-pce-
pcep-extension-native-ip-16 (work in progress), August
2021.
[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>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[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>.
[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>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
Wang & Wang Expires June 24, 2022 [Page 18]
Internet-Draft pce December 2021
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>.
[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>.
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in a Native IP
Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
<https://www.rfc-editor.org/info/rfc8735>.
[RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F.
Zhang, Ed., "Path Computation Element Communication
Protocol (PCEP) Extensions for GMPLS", RFC 8779,
DOI 10.17487/RFC8779, July 2020,
<https://www.rfc-editor.org/info/rfc8779>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
Authors' Addresses
Yue Wang
China Telecom
Beiqijia Town, Changping District
Beijing, Beijing 102209
China
Email: wangy73@chinatelecom.cn
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing, Beijing 102209
China
Email: wangaj3@chinatelecom.cn
Wang & Wang Expires June 24, 2022 [Page 19]