Handling the TC and TTL fields in a Label Stack Entry when the Generic Associated Channel Label is Present
draft-vainshtein-mpls-gal-tc-ttl-handling-01

Abstract

This document clarifies handling of the Traffic Class (TC) and Time-to-Live (TTL) fields of a Label Stack Entry that contains the Generic Associated Channel (G-ACh) Label (GAL). These clarifications are intended to aid interoperability of implementations.

Original handling was defined in RFC 5586, and this document updates that RFC.

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 December 18, 2015.

Copyright Notice

Copyright (c) 2015 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
• 2. Terminology
• 2.1. Requirements Language
• 2.2. Abbreviations
• 3. New Procedures
• 3.1. New Procedures for Handling the TC Field in an LSE That Contains the GAL
• 3.2. New Procedures for Handling the TTL Field in an LSE Containing GAL
• 3.3. Scope of the new Procedures
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgments
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

[RFC5586] introduced an alert mechanism for the Generic Associated Channel (G-ACh) that uses a Generic Associated Channel Label (GAL). In particular, [RFC5586] allocated one of the values from the special purpose label space to be the GAL, specified that the Label Stack Entry (LSE) containing GAL must be always at the bottom of the label stack in the case of MPLS transport profile (MPLS-TP) Label Switched Paths (LSPs), and that G-ACh packets must not be forwarded based on the GAL.

Per [RFC3032] each LSE contains, in addition to the label value and bottom-of-stack (BoS) flag, two additional fields:

• Traffic Class (TC) field - 3 bits (renamed from Experimental (EXP) field [RFC5462]). [RFC5586] defined that the handling of this field in an LSE that contains the GAL is as specified and referenced in RFC 5462.
• Time-to-Live (TTL) field - 8 bits. [RFC5586] defined that the handling of this field in an LSE that contains the GAL is in accordance with [RFC3443].

Implementations of [RFC5586] have encountered interoperability problems in their interpretation of these two fields when present in an LSE that contains the GAL. Section 4.2.1.1 of [RFC5586] states:

• The TTL field of the GAL LSE MUST be set to at least 1. The exact value of the TTL is application specific.

When this LSE becomes the top entry in the label stack (because the previous label has been popped) some receiving implementations have attempted to interpret the fields and this has resulted in errors, packet drops, or poor performance. In particular, packets with an LSE with TTL set to zero have been dropped as "expired" while those with TTL set to one can be trapped to the generic (slow) MPLS exception handler with appropriate rate limiting before the GAL is noticed (which would otherwise result in trapping the packet to a fast OAM handler). This document clarifies the rules for setting and processing them in the Label Stack Entry that includes the GAL.

The above-mentioned references are not useful for the implementers and testers because they don't give enough information about the correct processing actions. For example, [RFC5462] says only that the use of TC field for Quality of Service (QoS) and Explicit Congestion Notification (ECN) "is intended to be flexible'. On the other hand, while [RFC3443] is very detailed with regard to processing of the TTL field, it mainly deals with issues that are irrelevant for an LSE that contains the GAL.

This document defines handling of the TC and TTL fields in an LSE that contains GAL in an unambiguous way without referring to any other documents. It updates [RFC5586] in that regard.

2. Terminology

2.1. 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 [RFC2119].

2.2. Abbreviations

BoS: Bottom of Stack

G-ACh: Generic Associated Channel

GAL: Generic Associated Channel Label

LER: Label Edge Router

LSE: Label Stack Entry

LSP: Label Switching Path

LSR: Label Switching Router

PW: Pseudowire

TC: Traffic Class field (formerly named EXP)

TTL: Time-to-Live

3. New Procedures

3.1. New Procedures for Handling the TC Field in an LSE That Contains the GAL

Setting the value of the TC field in an LSE that contains the GAL is done by the LER that originates the G-ACh packet and is a matter of local policy for that LER. It is RECOMMENDED that implementations set the TC field of an LSE that contains the GAL to all zero (0b000).

The LER that inspects an LSE that contains the GAL MUST ignore the value of the TC field.

3.2. New Procedures for Handling the TTL Field in an LSE Containing GAL

Setting the value of the TTL in an LSE that contains the GAL is done by the LER that originates the G-ACh packet and is a matter of local policy for that LER. The LER that originates the G-ACh packet SHOULD NOT set this value to 0 or 1: this will avoid possible misinterpretation by the LER that inspects an LSE that contains the GAL if that LER does not comply with this document. It is RECOMMENDED that implementations set the TTL of an LSE that contains the GAL to 255.

The LER that examines an LSE that contains the GAL MUST ignore the value of the TTL field.

3.3. Scope of the new Procedures

[RFC5586] disallowed the use of the GAL in PWs, but that limitation was relaxed in [RFC6423].

The new procedures defined in this document for handling the TC field and the TTL field in an LSE that contains the GAL apply equally to all possible uses of the GAL including the so-called "Section G-ACh" where the GAL is the only label in the label stack, and the use of the GAL in LSPs and PWs.

4. IANA Considerations

This document makes no requests for IANA action.

5. Security Considerations

This document makes a minor update to the processing for MPLS packets containing the GAL and does not change any of the security fundamentals of MPLS. For a discussion of security considerations relating to MPLS, please refer to [RFC5920].

Note that the rules set out in this document specify that a receiver must ignore the values in the two MPLS LSE fields that are discussed. As such, this clarification removes a potential (and minor) attack vector where those fields could be malignly set and might cause incorrect action by the receiver.

6. Acknowledgments

The authors would like to thank Nadav Baadany whose question triggered this work, and Jeff Haas, Jie Dong, Mach Chen, and Huub van Helvoort for their comments on this document.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses