TOC 
Network Working GroupN. Bahadur, Ed.
Internet-DraftR. Aggarwal, Ed.
Intended status: Standards TrackD. Ward, Ed.
Expires: February 23, 2011Juniper Networks, Inc.
 T. Nadeau
 BT
 N. Sprecher
 Y. Weingarten
 Nokia Siemens Networks
 August 22, 2010


LSP-Ping and BFD encapsulation over ACH
draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01

Abstract

LSP-Ping and BFD for MPLS are existing and widely deployment OAM mechanisms for MPLS LSPs. This document describes an ACH encapsulation for LSP-Ping, that would enable use of LSP-Ping for networks where IP addressing is not in use. This document also clarifies the use of BFD for MPLS LSPs using ACH encapsulation, when IP addressing may not be available and/or it may not be desirable to encapsulate BFD packets in IP.

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 February 23, 2011.

Copyright Notice

Copyright (c) 2010 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. 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
    1.1.  Conventions used in this document
    1.2.  LSP-Ping and BFD over ACH
2.  LSP-Ping extensions
    2.1.  LSP-Ping packet over ACH for LSPs
    2.2.  LSP-Ping packet over ACH for PWs
    2.3.  Source Address TLV
    2.4.  MEP and MIP Identifier
3.  Running BFD over MPLS-TP LSPs
4.  Security Considerations
5.  IANA Considerations
    5.1.  New ACH Channel Types
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses



 TOC 

1.  Introduction

LSP-Ping [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) and BFD for MPLS [RFC5884] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs),” June 2010.) are OAM mechanisms for MPLS LSPs. This document describes an ACH encapsulation for LSP-Ping for networks that do not use IP addressing. When IP addressing is in use, the LSP-Ping procedures specified in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) apply as is. This document also clarifies the use of BFD for MPLS LSPs using ACH encapsulation [RFC5586] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.), when IP addressing may not be available and/or it may not be desirable to encapsulate BFD packets in IP.


 TOC 

1.1.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).


 TOC 

1.2.  LSP-Ping and BFD over ACH

In certain MPLS-TP deployment scenarios IP addressing might not be available or it may be preferred to use non-IP encapsulation for LSP-Ping and BFD packets. The remainder of this document defines extensions to LSP-Ping and procedures for using BFD, for such scenarios.

Section 2.1 (LSP-Ping packet over ACH for LSPs) and Section 2.2 (LSP-Ping packet over ACH for PWs) describe a new ACH code-point for performing LSP-Ping over ACH. Section 3 (Running BFD over MPLS-TP LSPs) describes procedures for using BFD over ACH.


 TOC 

2.  LSP-Ping extensions


 TOC 

2.1.  LSP-Ping packet over ACH for LSPs

[RFC5586] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.) defines an ACH mechanism for MPLS LSPs. This document defines a new ACH channel type for LSP-Ping, when IP addressing is not in use, for LSP-Ping over associated bi-directional LSPs and co-routed bi-directional LSPs. ACH TLVs MAY be associated with this channel type. 


    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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |     LSP-Ping Channel Type     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 1: LSP-Ping ACH Channel Type 

When ACH header is used, an LSP-Ping packet will look 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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         MPLS Label stack                      |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          GAL                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |     LSP-Ping Channel Type     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      ACH TLV Header                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          ACH TLVs                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      LSP-Ping payload                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 2: LSP-Ping packet with ACH 

When using LSP-Ping over the ACH header, the LSP-Ping Reply mode [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) in the LSP-Ping echo request MUST be set to 4 (Reply via application level control channel).


 TOC 

2.2.  LSP-Ping packet over ACH for PWs

[RFC4385] (Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN,” February 2006.) defines an PW-ACH mechanism for pseudowires. The ACH channel type for LSP-Ping defined in Section 2.1 (LSP-Ping packet over ACH for LSPs) will be re-used for pseudowires so that IP addressing is not needed when using LSP-Ping OAM over pseudowires.


 TOC 

2.3.  Source Address TLV

When sending LSP-Ping packets using ACH, without IP encapsulation, there MAY be a need to identify the source address of the packet. This source address will be specified via the Source Address TLV, being defined in [I‑D.ietf‑mpls‑tp‑ach‑tlv] (Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., Ward, D., and V. Manral, “Definition of ACH TLV Structure,” March 2010.). No more than 1 source address TLV MAY be present in a LSP-Ping packet. The source address MUST specify the address of the originator of the packet. If more than 1 such TLV is present in a LSP-Ping request packet, then an error code of 1 (Malformed echo request received), [ Section 3.1 [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.)], SHOULD be returned. If more than 1 source address TLV is present, then the packet SHOULD be dropped without further processing.


 TOC 

2.4.  MEP and MIP Identifier

When sending LSP-Ping packets using ACH, there MAY be a need to identify the maintenance end point (MEP) and/or the maintenance intermediate point (MIP) being monitored [I‑D.ietf‑mpls‑tp‑rosetta‑stone] (Sprecher, N., “A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.,” May 2010.). The MEP/MIP identifiers defined in [I‑D.ietf‑mpls‑tp‑identifiers] (Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” July 2010.) MAY be carried in the ACH TLVs [I‑D.ietf‑mpls‑tp‑ach‑tlv] (Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., Ward, D., and V. Manral, “Definition of ACH TLV Structure,” March 2010.) for identification.


 TOC 

3.  Running BFD over MPLS-TP LSPs

[RFC5884] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs),” June 2010.) describes how BFD can be used for Continuity Check of MPLS LSPs. The procedures described in [RFC5884] (Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs),” June 2010.) MUST be used when IP encapsulation is in use. This section clarifies the usage of BFD in the context of MPLS-TP LSPs when it is not desirable to use IP encapsulation. When using BFD over MPLS-TP LSPs, the BFD discriminator MUST either be signaled via LSP-Ping or be statically configured. The BFD packets MUST be sent over ACH when IP encapsulation is not used.

This document defines a new ACH channel type for BFD over G-ACH, when IP addressing is not in use, for running BFD over associated bi-directional LSPs and co-routed bi-directional LSPs. ACH TLVs MAY be associated with this channel type. 


    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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |  BFD over G-ACH Channel Type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 3: BFD over G-ACH Channel Type 

BFD packets, for both directions, MUST be sent over the MPLS-TP LSP and IP forwarding SHOULD NOT be used for the reverse path. The format of a BFD packet when using it as an OAM tool for MPLS-TP LSPs SHOULD be 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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         MPLS Label stack                      |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          GAL                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |  BFD over G-ACH Channel Type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      ACH TLV Header                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            ACH TLVs                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          BFD payload                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 4: BFD packet over MPLS-TP LSPs 

[RFC5885] (Nadeau, T. and C. Pignataro, “Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV),” June 2010.) specifies how BFD can be used over MPLS PWs. One MAY use BFD over G-ACH channel type to run BFD over PWs if ACH TLV support is needed.

BFD supports continuous fault monitoring and thus meets the pro-active Continuity Check and verification requirement specified in [RFC5860] (Vigoureux, M., Ward, D., and M. Betts, “Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks,” May 2010.). BFD SHOULD be run pro-actively. This function SHOULD be performed between End Points (MEPs) of PWs, LSPs and Sections. For point to multipoint Continuity Check, there is work in progress on using BFD for P2MP MPLS LSPs ( [I‑D.katz‑ward‑bfd‑multipoint] (Katz, D. and D. Ward, “BFD for Multipoint Networks,” February 2009.)) and this can be leveraged for MPLS-TP LSPs as well. Failure of a BFD session over a LSP can be used to trigger protection switching or other fault remedial procedures.

When sending BFD packets using ACH, there MAY be a need to identify the maintenance end point (MEP) being monitored. The MEP identifier defined in [I‑D.ietf‑mpls‑tp‑identifiers] (Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” July 2010.) can be carried in the ACH TLVs [I‑D.ietf‑mpls‑tp‑ach‑tlv] (Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., Ward, D., and V. Manral, “Definition of ACH TLV Structure,” March 2010.) for identification.


 TOC 

4.  Security Considerations

The draft does not introduce any new security considerations. Those discussed in [RFC4379] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.) are also applicable to this document.


 TOC 

5.  IANA Considerations


 TOC 

5.1.  New ACH Channel Types

New Channels type are defined in Section 2.1 (LSP-Ping packet over ACH for LSPs) and Section 3 (Running BFD over MPLS-TP LSPs). IANA is requested to assign new values from the "PW Associated Channel Type" registry, as per IETF consensus policy. 

    Value    Meaning
    -----    -------
     TBD     Associated Channel carries LSP-Ping packet
     TBD     Associated Channel carries BFD over G-ACH

 TOC 

6.  References


 TOC 

6.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC4379] Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” RFC 4379, February 2006 (TXT).
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN,” RFC 4385, February 2006 (TXT).

 TOC 

6.2. Informative References

[I-D.ietf-mpls-tp-ach-tlv] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., Ward, D., and V. Manral, “Definition of ACH TLV Structure,” draft-ietf-mpls-tp-ach-tlv-02 (work in progress), March 2010 (TXT).
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” draft-ietf-mpls-tp-identifiers-02 (work in progress), July 2010 (TXT).
[I-D.ietf-mpls-tp-rosetta-stone] Sprecher, N., “A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.,” draft-ietf-mpls-tp-rosetta-stone-02 (work in progress), May 2010 (TXT).
[I-D.katz-ward-bfd-multipoint] Katz, D. and D. Ward, “BFD for Multipoint Networks,” draft-katz-ward-bfd-multipoint-02 (work in progress), February 2009 (TXT).
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” RFC 5586, June 2009 (TXT).
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, “Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks,” RFC 5860, May 2010 (TXT).
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs),” RFC 5884, June 2010 (TXT).
[RFC5885] Nadeau, T. and C. Pignataro, “Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV),” RFC 5885, June 2010 (TXT).