Internet DRAFT - draft-li-pce-bfd
draft-li-pce-bfd
Network Working Group Z. Li
Internet-Draft X. Chen
Intended status: Informational Huawei Technologies
Expires: September 19, 2016 March 18, 2016
PCEP Extensions for Bidirectional Forwarding Detection
draft-li-pce-bfd-00
Abstract
This document describes the extensions to the PCEP to notify BFD
parameters for LSPs from PCE to PCC for PCE-initiated LSP. The
extensions include BFD protocol parameters and allow PCC to support
BFD for PCE-Initiated LSP whose BFD session is a bi-directional co-
routed channel.
Requirements Language
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 [RFC2119].
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
Li & Chen Expires September 19, 2016 [Page 1]
Internet-Draft PCEP Extensions for BFD 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Bootstrapping Bi-directional Co-routed BFD Session . . . . . 3
3.1. Bootstrapping BFD session without LSP Ping . . . . . . . 3
3.2. Bootstrapping BFD session with LSP Ping . . . . . . . . . 4
4. TLVs of PCEP Extensions for BFD . . . . . . . . . . . . . . . 4
4.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . . . 4
4.2. BFD Generic TLV . . . . . . . . . . . . . . . . . . . . . 5
4.3. BFD Authentication TLV . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
RFC 5884 [RFC5884] describes the applicability of BFD in relation to
LSP Ping for detecting rapidly a Multiprotocol Label Switching (MPLS)
Label Switched Path (LSP) data plane failure. It also describes
procedures for using BFD in MPLS environment. The LSP BFD detecting
can be bidirectional LSP or unidirectional LSP(so long as there is
some return path). If the path from ingress LSR to egress LSR is not
co-routed with the path from egress LSR to ingress LSR, the failure
to deliver BFD control packets from egress LSR to ingress LSR can
lead to false negatives, making ingress LSR deduces that the LSP has
failed.
I-D.ietf-pce-pce-initiated-lsp [I-D.ietf-pce-pce-initiated-lsp]
introduces the procedure of PCE-initiated LSPs under the stateful PCE
model. PCC will automatically set up the MPLS RSVP-TE LSP according
to the explicit path PCE provides. BFD session for the PCE-initiated
LSP can also be created dynamically and the return path is implicitly
the shortest path. Such BFD session whose forward and reverse paths
are possibly not co-routed has the same problem as mentioned above.
This document describes the extensions to the PCEP to notify BFD
parameters for LSPs from PCE to PCC for PCE-initiated LSP. The
extensions allow PCC to set up BFD session for PCE-Initiated LSP.
Li & Chen Expires September 19, 2016 [Page 2]
Internet-Draft PCEP Extensions for BFD March 2016
The BFD control packets can be exchanged over a bi-directional co-
routed channel.
The BFD protocol parameters such as detection time multiplier,
desired Min TX Interval, required Min RX Interval for PCE-initiated
LSP come from the public template or global configuration on PCC.
The extensions of PCEP include generic BFD protocol parameters too.
It can be used to notify PCC by PCE to adjust these parameters for
special LSP.
2. Terminology
BFD: Bidirectional Forwarding Detection
LSP: Label Switching Path
This document uses the following terms defined in RFC 5440 [RFC5440]:
PCC, PCE, PCEP.
The following term is defined in I-D.ietf-pce-pce-initiated-lsp
[I-D.ietf-pce-pce-initiated-lsp]:
PCE-initiated LSP: LSP that is instantiated as a result of a request
from the PCE.
3. Bootstrapping Bi-directional Co-routed BFD Session
PCE computes the path for one LSP from the ingress LSR to egress LSR
and initiates the creation of this LSP on ingress LSR. The LSP is
called as LSP1. PCE can initiate the creation of LSP on egress LSR
according to the co-routed path from egress LSR to ingress LSR. The
LSP is called as LSP2.
To make the BFD session for LSP1 over the co-routed path to avoid the
false detection there are two solutions as below:
3.1. Bootstrapping BFD session without LSP Ping
BFD for MPLS LSP uses LSP Ping carrying local descriminator to
bootstrapping BFD session in order to associate the FEC representing
the LSP with the BFD session indicated by descriminators. But PCE
knows the two co-routed LSPs and can allocate the pair of
descriminators for the co-routed LSPs.
PCE notify ingress LSR and egress LSR to set up BFD session for LSP1
by the BFD extensions of PCEP the pair of descriminators and notify
PCC not necessary to send LSP ping message and directly to set up BFD
Li & Chen Expires September 19, 2016 [Page 3]
Internet-Draft PCEP Extensions for BFD March 2016
session. My descriminator in BFD control packets along LSP1 is your
descriminator in BFD control packets along LSP2 and vice versa.
By this method the same BFD session is set up not only for LSP1 but
also LSP2.
How to guarantee the descriminators allocated by PCE and PCC are not
the same is out of scope of this document.
3.2. Bootstrapping BFD session with LSP Ping
I-D.ietf-mpls-bfd-directed [I-D.ietf-mpls-bfd-directed] defines the
BFD Reverse Path TLV as an extension to LSP Ping RFC 4379 [RFC4379]
and proposes that it to be used to instruct the egress BFD peer to
use specified path for its BFD control packets associated with the
particular BFD session.
After PCE initiates PCC to set up the LSP PCC delegates the MPLS
RSVP-LSP with LSP-IDENTIFIERS TLV including FEC information to PCE.
Therefore after ingress LSR and egress LSR set up the LSP1 and LSP2
independently they will delegate the LSP1 and LSP2 FEC information to
PCE independently.
PCE notify ingress LSR to set up BFD session for LSP1 carrying the
FEC information about the reverse LSP, LSP2. The information
received by ingress LSR via PCEP can be set to the BFD Reverse Path
TLV in the LSP Ping message. Following the procedure defined in
[draft-ietf-mpls-bfd-directed-02] the BFD session would be a bi-
directional co-routed channel and no false detection would be
notified.
PCE notify Egress LSR to set up BFD session for LSP2 following the
same process above.
By this method two BFD sessions are set up for LSP1 and LSP2
independently.
4. TLVs of PCEP Extensions for BFD
4.1. BFD Reverse Path TLV
The BFD Reverse Path TLV provides BFD parameters used to indicate the
reverse path for BFD session.
This is an optional TLV defined for the LSPA Object. This TLV is
included in the LSPA Object with PCUpd message.
Li & Chen Expires September 19, 2016 [Page 4]
Internet-Draft PCEP Extensions for BFD March 2016
The format of the BFD Reverse Path 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Reverse Path TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Path |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Reverse Path TLV
BFD Reverse Path TLV Type is 2 octets in length and the value is to
be assigned by IANA.
Length is 2 octets in length and defines the length in octets of the
Reverse Path field.
Reverse Path refers to Reverse Path defined in BFD Reverse Path TLV
in I-D.ietf-mpls-bfd-directed [I-D.ietf-mpls-bfd-directed].
4.2. BFD Generic TLV
The BFD Generic TLV provides BFD generic parameters of BFD session.
This is an optional TLV defined for the LSPA Object. This TLV is
included in the LSPA Object with PCInitiate or PCUpd message.
The format of the BFD Generic TLV is shown in the following figure:
Li & Chen Expires September 19, 2016 [Page 5]
Internet-Draft PCEP Extensions for BFD 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Generic TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Detect Mult | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Generic TLV
BFD Generic Path TLV Type is 2 octets in length and the value is to
be assigned by IANA.
Length is 2 octets in length and defines the fixed length 20.
The value of TLV refers to Generic BFD Control Packet Format in RFC
5880 [RFC5880].
4.3. BFD Authentication TLV
The BFD Authentication TLV provides BFD authentication parameters of
BFD session.
This is an optional TLV defined for the LSPA Object. This TLV is
included in the LSPA Object with PCInitiate or PCUpd message.
The format of the BFD Generic Path 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Authentication TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFD Authentication TLV
Li & Chen Expires September 19, 2016 [Page 6]
Internet-Draft PCEP Extensions for BFD March 2016
BFD Authentication TLV Type is 2 octets in length and the value is to
be assigned by IANA.
Length is 2 octets in length and defines the length in octets of the
value of BFD Authentication TLV.
The value of TLV refers to the optional Authentication Section in RFC
5880 [RFC5880].
5. IANA Considerations
TBD.
6. Security Considerations
TBD.
7. Normative References
[I-D.ietf-mpls-bfd-directed]
Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen,
"Bidirectional Forwarding Detection (BFD) Directed Return
Path", draft-ietf-mpls-bfd-directed-02 (work in progress),
March 2016.
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-05 (work in
progress), October 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
Li & Chen Expires September 19, 2016 [Page 7]
Internet-Draft PCEP Extensions for BFD March 2016
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <http://www.rfc-editor.org/info/rfc5884>.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Xia Chen
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: jescia.chenxia@huawei.com
Li & Chen Expires September 19, 2016 [Page 8]
