Path Ingress ProtectionsFutureweiBoston, MAUSAHuaimo.chen@futurewei.comFutureweimichael.mcbride@futurewei.com Verizon Inc.USAmehmet.toy@verizon.comVerizon Inc.13101 Columbia PikeSilver SpringMD 20904USA 301 502-1347gyan.s.mishra@verizon.comChina TelecomBeiqijia Town, Changping DistrictBeijing102209Chinawangaj3@chinatelecom.cnChina Mobile32 Xuanwumen West Ave, Xicheng DistrictBeijing100053Chinalizhengqiang@chinamobile.comChina Mobileliuyisong@chinamobile.comYandex LLCMoscowbhassanov@yahoo.comFujitsuUSAliulei.kddi@gmail.comVolta NetworksMcLeanVAUSAxufeng.liu.ietf@gmail.comThis document describes extensions to
Path Computation Element (PCE) communication Protocol (PCEP)
for fast protecting the ingress nodes of two types of paths
or tunnels, which are
Segment Routing (SR) paths and Bit Index Explicit Replication
Tree/Traffic Engineering (BIER-TE) paths.
The extensions comprise a foundation
for protecting the ingress nodes of different types of paths.
Based on this, the ingress protection of a new type of paths
can be easily supported.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 RFC 2119.The fast protection of a transit node in each type of
paths or tunnels have been proposed.
For example, the fast protection of a transit node in
a Segment Routing (SR) path or tunnel is described
in .
The fast protection of a transit node of a "Bit Index Explicit
Replication" (BIER) Traffic Engineering (BIER-TE) path or tunnel is
described in .
presents extensions to RSVP-TE for
the fast protection of the ingress node of
a traffic engineering (TE) Label Switching Path (LSP).
However, these documents do not discuss any protocol extensions
for the fast protection of
the ingress node of an SR path/tunnel, a BIER-TE path/tunnel,
or other type of paths/tunnels.This document fills that void and specifies protocol extensions to
Path Computation Element (PCE) communication Protocol (PCEP)
and
for fast protecting the ingress nodes of two types of paths:
SR paths and BIER-TE paths.
The extensions comprise a foundation
for protecting the ingress nodes of different types of paths.
Based on this, the ingress protection of a new type of paths
can be easily supported.Ingress node and ingress, fast protection and protection,
path ingress protection and ingress protection,
SR path and SR tunnel, as well as BIER-TE path and BIER-TE tunnel
will be used exchangeably in the following sections.The following terminologies are used in this document.
Path Computation Element or
Path Computation Element serverPCE communication ProtocolPath Computation ClientBit Index Explicit ReplicationBit Index Forwarding TableCustomer EdgeProvider EdgeTraffic EngineeringSegment RoutingLoop-Free AlternateTopology Independent LFABidirectional Forwarding DetectionVirtual Private NetworkLayer 3 VPNForwarding Information BaseThis section shows two examples of path ingress protection.
One is SR path ingress protection, and the other is
BIER-TE path ingress protection.
shows an example of protecting
ingress PE1 of a SR path, which is from ingress PE1 to egress PE3
and represented by *** in the figure.
In normal operations, CE1 sends the traffic with destination PE3
to ingress PE1,
which imports the traffic into the SR path.When CE1 detects the failure of ingress PE1, it switches the traffic to
backup ingress PE2, which imports the traffic from CE1 into a backup
SR path.
The backup path is from the backup ingress PE2 to the egress PE3
and represented by ### in the figure.
When the traffic is imported into the backup path,
it is sent to the egress PE3 along the path.
shows an example of protecting
ingress PE1 of a BIER-TE path,
which is from ingress PE1 to egress nodes PE3 and PE4.
This primary BIER-TE path is represented by *** in the figure.
The ingress of the primary BIER-TE path is called primary ingress.
The backup BIER-TE path is from ingress PE2 to
egress nodes PE3 and PE4,
which is represented by ### in the figure.
The ingress of the backup BIER-TE path is called backup ingress.In normal operations, CE1 sends the packets with
a multicast group and source
to ingress PE1,
which imports/encapsulates the packets into the BIER-TE path
through adding a BIER-TE header. The header contains the
BIER-TE path from ingress PE1 to egress nodes PE3 and PE4.When CE1 detects the failure of ingress PE1 using
a failure detection mechanism such as BFD,
it switches the traffic to backup ingress PE2,
which imports the traffic from CE1 into the backup BIER-TE path.
When the traffic is imported into the backup path,
it is sent to the egress nodes PE3 and PE4 along the path.
Given the traffic source (e.g., CE1), ingress (e.g., PE1) and egresses
(e.g., PE3 and PE4) of the primary BIER-TE path,
the PCE computes a backup ingress (e.g., PE2),
a backup BIER-TE path from the backup ingress to the egresses,
and sends the backup BIER-TE path to the PCC of the backup ingress.
It also sends the information about the backup ingress,
the primary ingress and the traffic
to the PCC of the traffic source (e.g., CE1).When the PCC of the traffic source receives
the information about the backup ingress,
the primary ingress and the traffic,
it sets up the fast detection of the primary ingress failure and
the switch over target backup ingress.
This setup lets the traffic source node switch the traffic (to be
sent to the primary ingress)
to the backup ingress when it detects the failure of the
primary ingress.When the PCC of the backup ingress receives the backup BIER-TE path,
it adds a forwarding entry into its BIFT.
This entry encapsulates the packets from the traffic source
in the backup BIER-TE path.
This makes the backup ingress send the traffic received from the
traffic source to the egress nodes via the backup BIER-TE path.This section describes the behavior of some nodes
connected to the ingress before and after the ingress
fails. These nodes are the traffic source (e.g., CE1) and
the backup ingress (e.g., PE2).
It presents three ways in which these nodes work together
to protect the ingress.
The first way is called source detect, where
the traffic source is responsible for fast
detecting the failure of the ingress.
The second way is called backup ingress detect, in which
the backup ingress is responsible for
fast detecting the failure of the ingress.
The third way is called both detect, where both the
traffic source and the backup ingress are responsible for
fast detecting the failure of the ingress.In normal operations, i.e., before the failure of
the ingress of a primary path such as a primary BIER-TE path,
the traffic source sends the traffic to the ingress of the
primary path.
The backup ingress (e.g., PE2) is ready to import the traffic
from the traffic source into the backup path such as
the backup BIER-TE path installed.When the traffic source detects the failure of the ingress,
it switches the traffic to the backup ingress,
which delivers the traffic to the egress nodes of the path
via the backup path.The traffic source (e.g., CE1) always sends the traffic to
both the ingress (e.g., PE1) of the primary path such as
the primary BIER-TE path
and the backup ingress (e.g., PE2).The backup ingress does not import any traffic
from the traffic source into the backup path
such as the backup BIER-TE path
in normal operations.
When it detects the failure of the ingress of the primary path,
it imports the traffic from the source into the backup path.For the backup ingress to fast detect the failure of
the primary ingress, it SHOULD directly connect to the
primary ingress. When a PCE computes a backup ingress
and a backup path, it SHOULD consider this.In normal operations, i.e., before the failure of the ingress,
the traffic source sends the traffic to the ingress of the
primary path such as the primary BIER-TE path.
When it detects the failure of the ingress,
it switches the traffic to the backup ingress.The backup ingress does not import any traffic
from the traffic source into the backup path such as
the backup BIER-TE path
in normal operations.
When it detects the failure of the ingress of the primary path,
it imports the traffic from the source into the backup path.A PCC runs on each of the edge nodes such as PEs
of a network normally.
A PCE runs on a server as a controller to communicate with PCCs.
PCE and PCCs work together to support protection for the ingress
of a path. The path is a
SR path, a BIER-TE path, or a path of another type.When a PCE and a PCC running on a backup ingress
establish a PCEP session between them,
they exchange their capabilities of supporting protection for
the ingress node of each of different types of paths.A new sub-TLV called INGRESS_PROTECTION_CAPABILITY is defined.
It is included in the PATH_SETUP_TYPE_CAPABILITY TLV with PST = TBD1
(suggested value 2 for path ingress protection)
in the OPEN object, which is exchanged in Open messages
when a PCC and a PCE establish a PCEP session between them.
Its format is illustrated below. TBD2 is to be assigned by IANA. 4. 2 octets. MUST be set to zero in transmission
and ignored on reception. 1 octet. Indicators for the types of paths
whose ingress protections are supported.
Two indicators are defined.
S : S = 1 indicating that the ingress
protection of a SR path is supported. B : B = 1 indicating that the ingress
protection of a BIER-TE path is supported. 1 octet. Two flags are defined.
D flag: A PCC sets this flag to 1 to indicate
that it is able to detect its adjacent node's failure quickly. A flag: A PCE sets this flag to 1 to request a PCC
to let the forwarding entry for the backup path/tunnel be Active.A PCC, which supports ingress protection for different types of paths,
sends a PCE an Open message containing INGRESS_PROTECTION_CAPABILITY
sub-TLV. This sub-TLV indicates that the PCC is capable of supporting
the ingress protection for the types of paths.For example, if a PCC supports ingress protection for
SR path and BIER-TE path, the PCC sends a PCE an Open message
containing INGRESS_PROTECTION_CAPABILITY
sub-TLV with S = 1 and B = 1.A PCE, which supports ingress protection for different types of paths,
sends a PCC an Open message containing INGRESS_PROTECTION_CAPABILITY
sub-TLV. This sub-TLV indicates that the PCE is capable of supporting
the ingress protection for the types of paths.If both a PCC and a PCE support
INGRESS_PROTECTION_CAPABILITY,
each of the Open messages sent by the PCC and PCE contains
PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=TBD1
and
an INGRESS_PROTECTION_CAPABILITY sub-TLV.If a PCE receives an Open message from a PCC without a
INGRESS_PROTECTION_CAPABILITY sub-TLV indicating
PCC's support for the ingress protection of a type of paths,
then the PCE MUST not send the PCC any request for ingress protection
of the type of paths.If a PCC receives an Open message from a PCE without a
INGRESS_PROTECTION_CAPABILITY sub-TLV indicating
PCE's support for the ingress protection of a type of paths,
then the PCC MUST ignore any request for ingress protection
of the type of paths from the PCE.If a PCC sets D flag to zero, then the PCE SHOULD send the PCC
an Open message with A flag set to one and the fast detection of
the failure of the primary ingress MUST be done by the traffic source.
When the PCE sends the PCC a message for initiating
a backup path,
the PCC MUST let the forwarding entry for the backup
path be Active.When a PCE and a PCC running on a traffic source node
establish a PCEP session between them,
they exchange their capabilities of supporting ingress protection.The PCECC-CAPABILITY sub-TLV defined in
is included
in the OPEN object in the PATH-SETUP-TYPE-CAPABILITY TLV,
which is exchanged in Open messages
when a PCC and a PCE establish a PCEP session between them. A new flag bit P is defined in the Flags field of the
PCECC-CAPABILITY sub-TLV:
P flag (for Ingress Protection):
if set to 1 by a PCEP speaker, the P flag indicates
that the PCEP speaker supports and is willing to handle the PCECC
based central controller instructions for ingress protection.
The bit
MUST be set to 1 by both a PCC and a PCE for the PCECC ingress
protection instruction
download/report on a PCEP session.This section specifies the extensions to PCEP for
the backup ingress and
the traffic source.
The extensions let the traffic source
fast detect the failure of the primary
ingress and switch the traffic to the backup ingress
when the traffic source detects the failure
of the primary ingress, or always send the traffic to both
the primary ingress and the backup ingress.The extensions let the backup ingress
always import the traffic
received from the traffic source with possible
service ID into the backup path, or import the traffic with possible
service ID into the backup path when the backup
ingress detects the failure of the primary ingress.
The following lists the combinations of Si and Bi (i = 1,2) for
different ways of failure detects.
S1 and B1.S2 and B2.S1 and B2.For the packets from the traffic source,
if the primary ingress (i.e., the ingress of the primary path)
encapsulates the packets with a service ID or label into
the path, the backup ingress MUST have this service ID
or label and encapsulates the packets with the service ID or label
into the backup path when the primary ingress fails.If the backup ingress is requested to detect the failure of
the primary ingress, it MUST have the information about the primary
ingress such as the address of the primary ingress.A new sub-TLV called INGRESS_PROTECTION is defined.
When a PCE sends a PCC a PCInitiate message for initiating
a backup path to protect the primary ingress node
of a primary path, the message contains this TLV
in the RP/SRP object.
Its format is illustrated below. TBD3 is to be assigned by IANA. Variable. 2 octets. MUST be set to zero in transmission
and ignored on reception. 1 octet. Indicating for the types of paths
whose ingress nodes are protected.
S : S = 1 indicating the ingress
protection of a SR path. B : B = 1 indicating the ingress
protection of a BIER-TE path. 1 octet. One flag is defined.
A flag bit: it is set to 1 or 0 by PCE.
1 is to request the backup ingress
to let the forwarding entry for the backup
path be Active always.
In this case, the traffic source detects the failure
of the primary ingress and switches the traffic
to the backup ingress when it detects the failure. 0 is to request the backup ingress
to detect the failure of the primary ingress and
let the forwarding entry for the backup
path be Active when the primary ingress fails.
In this case, the TLV includes the primary ingress address
in a Primary-Ingress sub-TLV.
The traffic source can send the traffic
to both the primary ingress and the backup ingress.
It may switch the traffic to the backup ingress from
the primary ingress when it detects the failure of
the primary ingress.
Three optional sub-TLVs are defined:
Primary-Ingress sub-TLV, Service sub-TLV, and
Traffic-Description sub-TLV.
The Traffic-Description sub-TLV
describes the traffic to be imported into the backup SR path.
The Multicast Flow Specification TLV for IPv4 or IPv6,
which is defined in ,
is used as a sub-TLV to
indicate the traffic to be imported into the backup
BIER-TE path.
A Primary-Ingress sub-TLV indicates the IP address of the primary ingress
node of a primary path.
It has two formats: one for primary ingress node IPv4 address
and the other for primary ingress node IPv6 address,
which are illustrated below. TBD4 is to be assigned by IANA. 4.4 octets. It represents
an IPv4 host address of the primary ingress node of a path. TBD5 is to be assigned by IANA. 16.16 octets. It represents
an IPv6 host address of the primary ingress node of a path.A Service sub-TLV contains a service ID or label to be added
into a packet to be carried by a path.
It has two formats: one for the service identified by a label
and the other for the service identified by a service
identifier (ID) of 32 or 128 bits,
which are illustrated below. TBD6 is to be assigned by IANA. 4.the least significant 20 bits.
It represents a label of 20 bits. TBD7 is to be assigned by IANA. 4 or 16. 4 or 16 octets.
It represents Identifier (ID) of a service
in 4 or 16 octets.A Traffic-Description sub-TLV describes the traffic to be imported
into a backup SR path.
Its format is illustrated below. TBD8 is to be assigned by IANA. Variable. Two optional sub-TLVs are defined.
One is FEC sub-TLV and the other interface sub-TLV.A FEC sub-TLV describes the traffic to be imported into
the backup path. It is an IP prefix with an optional
virtual network ID.
It has two formats: one for IPv4 and the other for IPv6,
which are illustrated below. TBD9 is to be assigned by IANA. Variable. Indicates the length of
the IPv4 Prefix. IPv4 Prefix rounded to octets. 2 octets.
This is optional. It indicates the ID of a virtual network. TBDa is to be assigned by IANA. Variable. Indicates the length of
the IPv6 Prefix. IPv6 Prefix rounded to octets. 2 octets.
This is optional. It indicates the ID of a virtual network.An Interface sub-TLV indicates the interface from which
the traffic is received and imported into the backup path.
It has three formats: one for interface index,
the other two for IPv4 and IPv6 address,
which are illustrated below. TBDb is to be assigned by IANA. 4.4 octets. It indicates the index of
an interface. TBDc is to be assigned by IANA. 4.4 octets. It represents
the IPv4 address of an interface. TBDd is to be assigned by IANA. 16.16 octets. It represents
the IPv6 address of an interface.If the traffic source is requested to detect the failure
of the primary ingress and switch the traffic (to be sent to
the primary ingress) to the backup ingress when the primary
ingress fails, it MUST have the information about the
backup ingress, the primary ingress and the traffic.
This information may be transferred via a
CCI object for INGRESS-PROTECTION
to the PCC of the traffic source node from a PCE.If the traffic source PCC does not accept the request from
the PCE or support the extensions, the PCE SHOULD have
the information about the behavior of the traffic source configured
such as whether it detects the failure of the primary
ingress. Based on the information,
the PCE instructs the backup ingress accordingly.The Central Control Instructions (CCI) Object is defined
in
for a PCE as a controller to send instructions for LSPs
to a PCC.
This document defines a new object-type (TBDt)
for ingress protection
based on the CCI object.
The body of the object with the new object-type is
illustrated below. The object may be in PCRpt, PCUpd,
or PCInitiate message.
It is the same as described in
. Two flag bits D and B are defined as follows:
D = 1 instructs the PCC of the traffic source
to Detect the failure
of the primary ingress and switch the traffic
to the backup ingress when it detects the failure. B = 1 instructs the PCC of the traffic source
to send the traffic
to Both the primary ingress and the backup ingress.Primary ingress TLV,
backup ingress TLV,
Traffic-Description TLV or
Multicast Flow Specification TLV.The primary ingress sub-TLV defined above is used as a TLV
to contain the information
about the primary ingress in the object.
The Traffic-Description sub-TLV defined above is used as a TLV
to contain the information about the
traffic for a SR path in the object.
The Multicast Flow Specification TLV for IPv4 or IPv6,
which is defined in ,
is used to contain the information about the
traffic for a BIER-TE path in the object.
A new TLV, called backup ingress TLV, is defined
to contain the information about the backup ingress in the object. A Backup-Ingress TLV indicates the IP address of the
ingress node of a backup path.
It has two formats: one for backup ingress node IPv4 address
and the other for backup ingress node IPv6 address,
which are illustrated below. They have the same format as
the Primary-Ingress sub-TLVs. TBDe is to be assigned by IANA. 4.4 octets. It represents
an IPv4 host address of the backup ingress. TBDf is to be assigned by IANA. 16.16 octets. It represents
an IPv6 host address of the backup ingress node.TBDThe authors of this document would like to thank
Dhruv Dhody and Robin Li
for their reviews and comments.TBD