One document matched: draft-chen-mpls-bfd-enhancement-01.txt
Differences from draft-chen-mpls-bfd-enhancement-00.txt
Network working group M. Chen
Internet Draft Huawei
Category: Standards Track N. So
Created: March 5, 2010 Verizon
Expires: September 2010 V. Hallivuori
Tellabs
BFD for MPLS LSPs Enhancement
draft-chen-mpls-bfd-enhancement-01.txt
Abstract
This document defines an enhancement to Bi-directional Forwarding
Detection (BFD) for MPLS LSPs [MPLS-BFD] that can be used to specify
the return path of BFD control packets for a specific BFD session.
Specifying co-routed or protected return path increases robustness
of BFD failure detection and reduces false positives. This document
also defines a way to avoid duplicate BFD sessions currently
encountered with Co-routed Bidirectional LSP and Associated
Bidirectional LSP. The enhancement halves the BFD sessions over
those LSPs, and allows a Co-routed Bidirectional LSPs or Associated
Bidirectional LSPs to be protected and switched as a single entity.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Chen, et al. Expires September 5, 2010 [Page 1]
Internet-Draft BFD for MPLS Enhancement March 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2009.
Copyright Notice
Copyright (c) 2009 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
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
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 RFC-2119 [RFC2119].
Table of Contents
1. Introduction.................................................2
2. Problem statements...........................................3
3. Enhancement to BFD for MPLS..................................4
4. Session Establishment........................................4
4.1. Session Control TLV.....................................6
4.2. The usage of IPv4/IPv6 RSVP Tunnel sub-TLVs.............6
5. Security Considerations......................................7
6. IANA Considerations..........................................7
6.1. Return code.............................................8
6.2. Session Control TLV.....................................8
7. Acknowledgments..............................................8
8. References...................................................8
8.1. Normative References....................................8
8.2. Informative References..................................9
Authors' Addresses.............................................10
1. Introduction
This document defines an enhancement to Bi-directional Forwarding
Detection (BFD) for MPLS LSPs [MPLS-BFD] that can be used to specify
Chen, et al. Expires September 5, 2010 [Page 2]
Internet-Draft BFD for MPLS Enhancement March 2010
the return path of BFD control packets for a specific BFD session.
In traffic engineered networks, LSPs usually do not follow IP
routing or there are multiple LSPs between same nodes. Specifying
return path to be congruent with forward path ensures that failures
in other paths (e.g. shortest path for IP routing) do not cause BFD
failure detection for the forward path. This extension hence
increases robustness of BFD based failure detection, especially in
LSP 1:1 type protection cases. Also specifying FRR protected LSP as
return path can increase robustness.
This document also defines a way to avoid duplicate BFD sessions
when BFD is used for Bidirectional LSP or for a pair of
unidirectional LSPs. This extension allows a Bidirectional LSP or a
pair of unidirectional LSPs to be protected and switched as a whole
entity.
In this document, term Bidirectional LSP includes Co-routed
Bidirectional LSP defined in [RFC 3471] [RFC 3473] and Associated
Bidirectional LSP (that is constructed from a pair of unidirectional
LSPs).
2. Problem statements
BFD for MPLS LSPs (BFDoMPLS) is defined in [BFD-MPLS] and used for
detecting end-to-end reachability of LSP. BFD for MPLS is an
important feature for the packetized MPLS converged network, as it
provides end-to-end connectivity verification. Reverse direction of
MPLS for BFD follows routing, and hence it can not be used for
protection decisions, if more than one alternate path is available.
LSP Ping [RFC 4379] is used to bootstrap the BFD sessions. With the
current mechanisms defined in [BFD-MPLS]:
1. For each direction of a LSP, a separate BFD session is required
to be established. The return packets from the terminator of a
BFD session to the initiator could be either IP or MPLS
encapsulated, and the choice is of the terminator. That means
for unidirectional LSP, only one session is needed, but for a
Bidirectional LSP, there will be two BFD sessions. This will
result in not only doubling the BFD sessions over the LSP, but
sometimes failing to perform protection and switching when the
Bidirectional LSP is desired to be operated as a single entity.
This is due to the two BFD sessions that are individually
responsible for each direction of the Bidirectional LSP having
no inherent relationship. It is possible that one session
detects failure and the other does not, with the result that
Chen, et al. Expires September 5, 2010 [Page 3]
Internet-Draft BFD for MPLS Enhancement March 2010
one direction switches while the other does not. This can cause
unexpected operational problems.
2. For a specific BFD session, the return path (which carries the
BFD control packets), which could be an IP path or a LSP is
selected by the egress. The choice is a local decision of the
egress, and egress does not have enough information to perform
a choice that would produce both directions of BFD transiting
same path. In some cases, it is very valuable to specify the
return path for a BFD session. For example, selecting a more
reliable return path (e.g., TE LSP with FRR protection) could
improve the reliability of reply BFD control packets or
selecting co-routed LSP would allow use of BFDoMPLS as trigger
for LSP protection.
3. Enhancement to BFD for MPLS
The enhancement described in this document improves upon "BFD for
MPLS LSPs" [BFD-MPLS], in the following areas:
1. Allows LSP ingress node to signal the desired return path for
any BFDoMPLS session.
2. Allows operator to provision BFD on both forwarding and return
path of Bidirectional LSPs with a single BFD session. This
extension halves the number BFD sessions over the LSP, and
enables that a Bidirectional LSP could be protected and
switched as a single entity.
3. Allows operator to provision BFD on two unidirectional LSPs
(one for each direction) with a single BFD session. This
reduces number of BFD sessions, and hence reduces control plane
load. However in some cases (e.g. where make-before-break is
used or the operator wants each of the two unidirectional LSPs
to be operated separately), this is undesirable, and hence this
feature is optional.
All the goals listed above are only relevant to BFD session
establishment, so the enhancement defined in this document is mainly
focus on BFD session establishment. The "return path specified"
mechanisms defined in [LSP-PING-RP] are used in this document.
4. Session Establishment
As defined in [BFD-MPLS], a BFD session is boot-strapped by LSP Ping.
All the procedures for session establishment defined in [BFD-MPLS]
Chen, et al. Expires September 5, 2010 [Page 4]
Internet-Draft BFD for MPLS Enhancement March 2010
apply here. In addition to that, a RP TLV defined in [LSP-PING-RP]
MUST be carried in the echo request. This is used to notify the
egress LSR to select the return path of the BFD session. The return
path is identified by the FEC sub-TLV encoded in the RP TLV.
Except for "Any Candidate sub-TLV" that is defined in [LSP-PING-RP],
any other sub-TLVs are applicable to be included in RP TLV to
explicitly specify the return path of a BFD session.
If RP TLV is present in LSP ping message that setups BFD for MPLS
sessions:
o LSP ping reply packet MUST be sent as specified in [LSP-PING-RP].
o BFD for MPLS packets MUST be sent via same reply channel used
for LSP ping reply packets.
o If selected path becomes unavailable (and no other path meeting
specifications in previously received RP TLV is present),
transmission of BFD packets MUST be interrupted. Transmission
of BFD packets MUST resume, if return path LSP becomes
available.
It is permissible for multiple BFD for MPLS sessions to use same
return path -- when node does make-before-break (MBB), it can signal
separate BFD for MPLS session to test new LSP before taking it into
use.
In this document, a new TLV, Session Control TLV is defined. Session
Control TLV is used to notify the egress LSR whether to establish
another BFD session for the backward direction of a Bidirectional
LSP or a pair of unidirectional LSPs (one for each direction). If
Session Control TLV is carried, the egress LSR MUST not initiate
another separate BFD session for the backward direction of the
Bidirectional LSP or the pair of unidirectional LSPs. If BFD session
has been provisioned to both nodes, the node with a numerically
larger IP address (comparison using signaled LSP endpoint addresses,
for example, the terminator could use its own Router ID for
comparison with the source IP address of the received echo request.)
shall initiate signaling. The initiator MAY carry an IP address
(e.g., Router ID) of its own in the Source Address TLV [MPLS-TP-TLV]
when IP forwarding is disabled (e.g., the scenario of MPLS-TP
without IP forwarding). If node with the larger IP receives LSP ping
message signaling BFD session with Session Control TLV, LSP ping
reply must be transmitted with "Backward direction BFD session
exists" to the ingress LSR. If there is no Session Control TLV
Chen, et al. Expires September 5, 2010 [Page 5]
Internet-Draft BFD for MPLS Enhancement March 2010
carried in the echo request, it's up to the egress LSR to decide
whether to initiate another BFD session for the backward direction
LSP, this is the same as the definition in [BFD-MPLS].
When received an echo request with the reply mode set to "Reply via
specified path" [LSP-PING-RP], if the receiver does not know the
reply mode, an echo reply with the return code set to "Malformed
echo request" and the Subcode set to zero SHOULD be send back to the
initiator. The BFD session will not be established in this case.
When provisioning a single BFD to a bidirectional LSP or a pair of
unidirectional LSPs, in case of the forwarding direction of session
is OK but the reverse direction is not, the initiator MUST not send
BFD control packets on the session until the echo reply is received
from the terminator. And the terminator MUST not send BFD control
packets onto the BFD session until the first BFD control packet is
received from the initiator.
4.1. Session Control TLV
Session Control TLV is an optional TLV, it is carried in echo
request to notify the egress LSR not to initiate another BFD session
for the backward direction of a Bidirectional LSP or pair of
unidirectional LSPs (one for each direction). The format of Session
Control TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Control Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session Control TLV Type field is 2 octets in length, and the
type value is TBD.
Length field is 2 octets in length, the value of length field SHOULD
be 0, unless any sub-TLVs (defined in future) are present.
4.2. The usage of IPv4/IPv6 RSVP Tunnel sub-TLVs
IPv4/IPv6 RSVP Tunnel sub-TLVs are defined in [LSP-PING-RP], which
are used to notify the egress LSR of a specific LSP how to choose
the return path for an echo reply.
In this document, these sub-TLVs are re-used to notify the egress
LSR of a specific LSP how to choose the return path of a BFD session.
Chen, et al. Expires September 5, 2010 [Page 6]
Internet-Draft BFD for MPLS Enhancement March 2010
As stated in section 2 of this document, it is possible to have
multiple parallel LSPs between the ingress and egress LSRs. In a
typical network example, a group of parallel LSPs have the same
tunnel ID but different LSP IDs. There is one primary and one or
more secondary LSPs in each direction. When establishing a BFD
session for an LSP, it is common for the primary LSP to choose the
primary as the return path and the secondary LSP to choose the
secondary as the return path. With the IPv4/IPv6 Tunnel sub-TLVs,
operators don't have to specify a specific return LSP. They just
need to specify from which tunnel the return LSP should be chosen,
and specify the type (e.g., primary or secondary) of the return LSP.
The egress LSR will then choose the proper return path.
Use of IPv4/IPv6 RSVP Tunnel sub-TLVs permits MBB on return path of
BFD session. If a specific RSVP session would be selected (with FEC
containing LSP ID), return path would be interrupted if egress node
would do MBB for the return path. This is due to the fact that MBB
is based on signaling new LSP with different LSP ID and then
deleting old LSP - after MBB selected return path would no longer be
available. MBB is common occurrence as it is often used for changing
LSP attributes, such as reserved bandwidth. With the extensions in
[LSP-PING-RP], desired LSP can be selected without limiting use of
MBB.
5. Encapsulation
In this document, since the BFD control packet from the session
terminator to initiator MUST be encapsulated in a MPLS label stack,
it MUST have a well known destination port 3784 [BFD-IP].
6. Security Considerations
Security considerations discussed in [BFD-MPLS], [BFD], [BFD-MHOP]
and [RFC4379] apply to this document.
Limitations on permitted return path LSPs specified [LSP-PING-RP]
apply to extensions specified in this document.
7. IANA Considerations
IANA is requested to make the following allocations from registries
under its control.
Chen, et al. Expires September 5, 2010 [Page 7]
Internet-Draft BFD for MPLS Enhancement March 2010
7.1. Return code
IANA is requested to assign a new return code as follows:
Type # Value Field
------ -----------
11 Backward direction session exists
7.2. Session Control TLV
IANA is requested to assign a new TLV type (TBD) from the range of
0-16383. We suggest that the value 21 be assigned for the new RP TLV
type.
Type Value Field
----- -----------
21 Session Control
8. Acknowledgments
The authors would like to thank Greg Mirsky, Xinchun Guo and Wei Cao
for their review and comments to this document.
9. Contributors
Vishwas Manral
IP Infusion
Almora, Uttarakhand
India
EMail: vishwas@ipinfusion.com
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 4379] K. Kompella., et al., "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February
2006.
Chen, et al. Expires September 5, 2010 [Page 8]
Internet-Draft BFD for MPLS Enhancement March 2010
[BFD-MPLS] R. Aggarwal., et al., "BFD For MPLS LSPs", draft-ietf-
bfd-mpls, working in progress.
[LSP-PING-RP] M. Chen., et al., "Return Path Specified LSP Ping",
draft-chen-mpls-return-path-specified-lsp-ping, working in
progress.
[BFD-IP] D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)",
draft-ietf-bfd-v4v6-1hop-08.txt.
[MPLS-TP-TLV] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G.,
and D. Ward, "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-01 (work in progress),
February 2010.
10.2. Informative References
[BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths",
draft-ietf-bfd-multihop-06.txt
Chen, et al. Expires September 5, 2010 [Page 9]
Internet-Draft BFD for MPLS Enhancement March 2010
Authors' Addresses
Mach(Guoyi) Chen
Huawei Technology Co., Ltd.
No. 9 Xinxi Road
Shangdi Information Industry Base
Hai-Dian District, Beijing 100085
China
Email: mach@huawei.com
So Ning
Verizon Inc.
2400 N. Glenville Rd.,
Richardson, TX 75082
Phone: +1 972-729-7905
EMail: ning.so@verizonbusiness.com
Ville Hallivuori
Tellabs
Sinimaentie 6 C
FI-02630 Espoo, Finland
EMail: ville.hallivuori@tellabs.com
Chen, et al. Expires September 5, 2010 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 10:35:59 |