diff options
Diffstat (limited to 'doc/rfc/rfc5586.txt')
| -rw-r--r-- | doc/rfc/rfc5586.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5586.txt b/doc/rfc/rfc5586.txt new file mode 100644 index 0000000..9f57a55 --- /dev/null +++ b/doc/rfc/rfc5586.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group M. Bocci, Ed. +Request for Comments: 5586 M. Vigoureux, Ed. +Updates: 3032, 4385, 5085 Alcatel-Lucent +Category: Standards Track S. Bryant, Ed. + Cisco Systems + June 2009 + + + MPLS Generic Associated Channel + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +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 in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + This document generalizes the applicability of the pseudowire (PW) + Associated Channel Header (ACH), enabling the realization of a + control channel associated to MPLS Label Switched Paths (LSPs) and + MPLS Sections in addition to MPLS pseudowires. In order to identify + the presence of this Associated Channel Header in the label stack, + this document also assigns one of the reserved MPLS label values to + the Generic Associated Channel Label (GAL), to be used as a label + based exception mechanism. + + + + + + + + + + + + +Bocci, et al. Standards Track [Page 1] + +RFC 5586 G-ACh and GAL June 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Requirements Language and Terminology . . . . . . . . . . 5 + 2. Generic Associated Channel Header . . . . . . . . . . . . . . 5 + 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Allocation of Channel Types . . . . . . . . . . . . . . . 6 + 3. ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7 + 3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9 + 4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9 + 4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10 + 4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10 + 4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13 + 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 + 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15 + 7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 15 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 + + + + + + + + + + + + + + + + + + + + + + + + +Bocci, et al. Standards Track [Page 2] + +RFC 5586 G-ACh and GAL June 2009 + + +1. Introduction + + There is a need for Operations, Administration, and Maintenance (OAM) + mechanisms that can be used for fault detection, diagnostics, + maintenance, and other functions on a pseudowire (PW) and a Label + Switched Path (LSP). These functions can be used between any two + Label Edge Routers (LERs)/Label Switching Router (LSRs) or + Terminating Provider Edge routers (T-PEs)/Switching Provider Edge + routers (S-PEs) along the path of an LSP or PW, respectively + [MPLS-TP]. Some of these functions can be supported using existing + tools such as Virtual Circuit Connectivity Verification (VCCV) + [RFC5085], Bidirectional Forwarding Detection for MPLS LSPs (BFD- + MPLS) [BFD-MPLS], LSP-Ping [RFC4379], or BFD-VCCV [BFD-VCCV]. + However, a requirement has been indicated to augment this set of + maintenance functions, in particular when MPLS networks are used for + packet transport services and transport network operations [OAM-REQ]. + Examples of these functions include performance monitoring, automatic + protection switching, and support for management and signaling + communication channels. These tools MUST be applicable to, and + function in essentially the same manner (from an operational point of + view) on MPLS PWs, MPLS LSPs, and MPLS Sections. They MUST also + operate in-band on the PW or LSP such that they do not depend on + Packet Switched Network (PSN) routing or on user traffic, and MUST + NOT depend on dynamic control plane functions. + + VCCV [RFC5085] can use an Associated Channel Header (ACH) to provide + a PW associated control channel between a PW's endpoints, over which + OAM and other control messages can be exchanged. This document + generalizes the applicability of the ACH to enable the same + associated control channel mechanism to be used for Sections, LSPs, + and PWs. The associated control channel thus generalized is known as + the Generic Associated Channel (G-ACh). The ACH, specified in RFC + 4385 [RFC4385], may be used with additional code points to support + additional MPLS maintenance functions on the G-ACh. + + Generalizing the applicability of the ACH to LSPs and Sections also + requires a method to identify that a packet contains an ACH followed + by a non-service payload. Therefore, this document also defines a + label-based exception mechanism that serves to inform an LSR (or LER) + that a packet it receives on an LSP or Section belongs to an + associated control channel. The label used for that purpose is one + of the MPLS reserved labels and is referred to as the GAL (G-ACh + Label). The GAL mechanism is defined to work together with the ACH + for LSPs and MPLS Sections. + + RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms + that enable an MPLS LSR to identify and process MPLS OAM packets when + these are encapsulated in an IP header. These alert mechanisms are + + + +Bocci, et al. Standards Track [Page 3] + +RFC 5586 G-ACh and GAL June 2009 + + + based, for example, on Time To Live (TTL) expiration and/or on the + use of an IP destination address in the range of 127.0.0.0/8 or 0:0: + 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. These + mechanisms are the default mechanisms for identifying MPLS OAM + packets when encapsulated in an IP header. However, it may not + always be possible to use these mechanisms in some MPLS applications, + e.g., MPLS Transport Profile (MPLS-TP) [MPLS-TP], particularly when + IP-based demultiplexing cannot be used. This document defines a + mechanism that is RECOMMENDED for identifying and encapsulating MPLS + OAM and other maintenance messages when IP based mechanisms such as + those used in [RFC4379] and [BFD-MPLS] are not available. Yet, this + mechanism MAY be used in addition to IP-based mechanisms. + + Note that, in this document, maintenance functions and packets should + be understood in the broad sense. That is, a set of maintenance and + management mechanisms that include OAM, Automatic Protection + Switching (APS), Signaling Communication Channel (SCC), and + Management Communication Channel (MCC) messages. + + Also note that the GAL and ACH are applicable to MPLS and PWs in + general. This document specifies general mechanism and uses MPLS-TP + as an example application. The application of the GAL and ACH to + other specific MPLS uses is outside the scope of this document. + +1.1. Objectives + + This document defines a mechanism that provides a solution to the + extended maintenance needs of emerging applications for MPLS. It + creates a generic control channel mechanism that may be applied to + MPLS LSPs and Sections, while maintaining compatibility with the PW + associated channel. It also normalizes the use of the ACH for PWs in + a transport context, and defines a label-based exception mechanism to + alert LERs/LSRs of the presence of an ACH after the bottom of the + label stack. + +1.2. Scope + + This document defines the encapsulation header for Section, LSP, and + PW associated control channel messages. + + This document does not define how associated control channel + capabilities are signaled or negotiated between LERs/LSRs or between + PEs, nor does it define the operation of various OAM functions. + + This document does not deprecate existing MPLS and PW OAM mechanisms. + + + + + + +Bocci, et al. Standards Track [Page 4] + +RFC 5586 G-ACh and GAL June 2009 + + +1.3. Requirements Language and Terminology + + 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]. + + This document uses the following additional terminology: + + ACH: Associated Channel Header + + G-ACh: Generic Associated Channel + + GAL: G-ACh Label + + G-ACh packet: Any packet containing a message belonging to a protocol + that is carried on a PW, LSP, or MPLS Section associated control + channel. Examples include maintenance protocols such as OAM + functions, signaling communications, or management communications. + + The terms "Section" and "Concatenated Segment" are defined in + [TP-REQ] as follows (note that the terms "Section" and "Section Layer + Network" are synonymous): + + Section Layer Network: A section layer is a server layer (which may + be MPLS-TP or a different technology) that provides for the transfer + of the section layer client information between adjacent nodes in the + transport path layer or transport service layer. Note that G.805 + [G805] defines the section layer as one of the two layer networks in + a transmission media layer network. The other layer network is the + physical media layer network. + + Concatenated Segment: A serial-compound link connection as defined in + [G805]. A concatenated segment is a contiguous part of an LSP or + multi-segment PW that comprises a set of segments and their + interconnecting nodes in sequence. + +2. Generic Associated Channel Header + + VCCV [RFC5085] defines three Control Channel (CC) Types that may be + used to exchange OAM messages through a PW. CC Type 1 uses an ACH + and is referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router + Alert Label to indicate VCCV packets and is referred to as "Out-of- + Band VCCV"; CC Type 3 uses the TTL to force the packet to be + processed by the targeted router control plane and is referred to as + "MPLS PW Label with TTL == 1". + + + + + + +Bocci, et al. Standards Track [Page 5] + +RFC 5586 G-ACh and GAL June 2009 + + +2.1. Definition + + The use of the ACH, previously limited to PWs, is here generalized to + also apply to LSPs and to Sections. Note that for PWs, the PWE3 + control word [RFC4385] MUST be present in the encapsulation of user + packets when the ACH is used to realize the associated control + channel. + + The ACH used by CC Type 1 is depicted in figure below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1|Version| Reserved | Channel Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Associated Channel Header + + In the above figure, the first nibble is set to 0001b to indicate a + control channel associated with a PW, LSP, or Section. The Version + field is set to 0, as specified in RFC 4385 [RFC4385]. Bits 8 to 15 + of the ACH are reserved and MUST be set to 0 and ignored on + reception. Bits 16 to 31 are used to encode the possible Channel + Types. This 16-bit field is in network byte order. + + Note that VCCV [RFC5085] also includes mechanisms for negotiating the + Control Channel and Connectivity Verification (i.e., OAM function) + Types between PEs. It is anticipated that similar mechanisms will be + applied to LSPs. Such application will require further + specification. However, such specification is beyond the scope of + this document. + + The G-ACh MUST NOT be used to transport user traffic. + +2.2. Allocation of Channel Types + + The Channel Type field indicates the type of message carried on the + associated control channel, e.g., IPv4 or IPv6 if IP demultiplexing + is used for messages sent on the associated control channel, or OAM + or other maintenance function if IP demultiplexing is not used. For + associated control channel packets where IP is not used as the + multiplexer, the Channel Type indicates the specific protocol carried + in the associated control channel. + + Values for the Channel Type field currently used for VCCV are + specified elsewhere, e.g., in RFC 4446 [RFC4446] and RFC 4385 + [RFC4385]. Additional Channel Type values and the associated + + + + +Bocci, et al. Standards Track [Page 6] + +RFC 5586 G-ACh and GAL June 2009 + + + maintenance functionality will be defined in other documents. Each + document, specifying a protocol solution relying on the ACH, MUST + also specify the applicable Channel Type field value. + + Note that these values are allocated from the PW Associated Channel + Type registry [RFC4446], but this document modifies the existing + policy to accommodate a level of experimentation. See Section 10 for + further details. + +3. ACH TLVs + + In some applications of the generalized associated control channel, + it is necessary to include one or more ACH TLVs to provide additional + context information to the G-ACh packet. One use of these ACH TLVs + might be to identify the source and/or intended destination of the + associated channel message. However, the use of this construct is + not limited to providing addressing information nor is the + applicability restricted to transport network applications. + + If the G-ACh message MAY be preceded by one or more ACH TLVs, then + this MUST be explicitly specified in the definition of an ACH Channel + Type. If the ACH Channel Type definition does state that one or more + ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow + the ACH. If no ACH TLVs are required in a specific associated + channel packet, but the Channel Type nevertheless defines that ACH + TLVs MAY be used, an ACH TLV Header MUST be present but with a length + field set to zero to indicate that no ACH TLV follow this header. + + If an ACH Channel Type specification does not explicitly specify that + ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used. + +3.1. ACH TLV Payload Structure + + This section defines and describes the structure of an ACH payload + when an ACH TLV Header is present. + + The following figure (Figure 2) shows the structure of a G-ACh packet + payload. + + + + + + + + + + + + + +Bocci, et al. Standards Track [Page 7] + +RFC 5586 G-ACh and GAL June 2009 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACH TLV Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ~ + ~ zero or more ACH TLVs ~ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ~ + ~ G-ACh Message ~ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: G-ACh Packet Payload + +3.2. ACH TLV Header + + The ACH TLV Header defines the length of the set of ACH TLVs that + follow. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: ACH TLV Header + + The Length field specifies the length in octets of the complete set + of TLVs including sub-TLVs that follow the ACH TLV Header. A length + of zero indicates that no ACH TLV follow this header. Note that no + padding is required for the set of ACH TLVs. + + The Reserved field is for future use and MUST be set to zero on + transmission and ignored on reception. + +3.3. ACH TLV Object + + ACH TLVs MAY follow an ACH TLV Header. The structure of ACH TLVs is + defined and described in this section. + + An ACH TLV consists of a 16-bit Type field, followed by a 16-bit + Length field that specifies the number of octets of the Value field, + which follows the Length field. This 32-bit word is followed by zero + or more octets of Value information. The format and semantics of the + Value information are defined by the TLV Type as recorded in the TLV + + + + +Bocci, et al. Standards Track [Page 8] + +RFC 5586 G-ACh and GAL June 2009 + + + Type registry. See Section 10 for further details. Note that the + Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding + is required for individual TLVs or sub-TLVs. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TLV Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ~ + ~ Value ~ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: ACH TLV Format + +4. Generalized Exception Mechanism + + Generalizing the associated control channel mechanism to LSPs and + Sections also requires a method to identify that a packet contains an + ACH followed by a non-service payload. This document specifies that + a label is used for that purpose and calls this special label the + G-ACh Label (GAL). One of the reserved label values defined in RFC + 3032 [RFC3032] is assigned for this purpose. IANA assigned the value + 13 to the GAL. + + The GAL provides an alert based exception mechanism to: + + o differentiate specific packets (i.e., G-ACh packets) from others, + such as user-plane ones. + + o indicate that the ACH appears immediately after the bottom of the + label stack. + + The GAL MUST only be used where both these purposes apply. + +4.1. Relationship with Existing MPLS OAM Alert Mechanisms + + RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms + that enable an MPLS LSR to identify and process MPLS OAM packets when + these are encapsulated in an IP header. These alert mechanisms are + based, for example, on Time To Live (TTL) expiration and/or on the + use of an IP destination address in the range of 127.0.0.0/8 or 0:0: + 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. + + These mechanisms are the default mechanisms for identifying MPLS OAM + packets when encapsulated in an IP header although the mechanism + defined in this document MAY also be used. + + + +Bocci, et al. Standards Track [Page 9] + +RFC 5586 G-ACh and GAL June 2009 + + +4.2. GAL Applicability and Usage + + In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, + Concatenated Segments of LSPs, and with Sections, and MUST NOT be + used with PWs. It MUST always be at the bottom of the label stack + (i.e., S bit set to 1). However, in other MPLS environments, this + document places no restrictions on where the GAL may appear within + the label stack or its use with PWs. Where the GAL is at the bottom + of the label stack (i.e., S bit set to 1), then it MUST always be + followed by an ACH. + + The GAL MUST NOT appear in the label stack when transporting normal + user-plane packets. Furthermore, when present, the GAL MUST NOT + appear more than once in the label stack. + + A receiving LSR, LER, or PE MUST NOT forward a G-ACh packet to + another node based on the GAL label. + +4.2.1. GAL Processing + + The Traffic Class (TC) field (formerly known as the EXP field) of the + Label Stack Entry (LSE) containing the GAL follows the definition and + processing rules specified and referenced in [RFC5462]. + + The Time-To-Live (TTL) field of the LSE that contains the GAL follows + the definition and processing rules specified in [RFC3443]. + +4.2.1.1. MPLS Label Switched Paths and Segments + + The following figure (Figure 5) depicts two LERs (A and D) and two + LSRs (B and C) for a given LSP that is established from A to D and + switched in B and C. + + +---+ +---+ +---+ +---+ + | A |-------------| B |-------------| C |-------------| D | + +---+ +---+ +---+ +---+ + + Figure 5: Maintenance over an LSP + + In this example, a G-ACh exists on the LSP that extends between LERs + A and D, via LSRs B and C. Only A and D may initiate new G-ACh + packets. A, B, C, and D may process and respond to G-ACh packets. + + The following figure (Figure 6) depicts the format of an MPLS-TP + G-ACh packet when used for an LSP. + + + + + + +Bocci, et al. Standards Track [Page 10] + +RFC 5586 G-ACh and GAL June 2009 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LSP Label | TC |S| TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | GAL | TC |S| TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACH TLV Header (if present) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ~ + ~ Zero or more ACH TLVs ~ + ~ (if present) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ~ + ~ G-ACh Message ~ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: G-ACh Packet Format for an LSP + + Note that it is possible that the LSP may be tunneled in another LSP + (e.g., if an MPLS Tunnel exists between B and C), and as such other + LSEs may be present in the label stack. + + To send a G-ACh message on the LSP associated control channel, the + LER (A) generates a G-ACh message, to which it MAY prepend an ACH TLV + Header and appropriate ACH TLVs. It then adds an ACH, onto which it + pushes a GAL LSE. Finally, the LSP Label LSE is pushed onto the + resulting packet. + + o The TTL field of the GAL LSE MUST be set to at least 1. The exact + value of the TTL is application specific. See Section 4.2.1 for + definition and processing rules. + + o The S bit of the GAL MUST be set according to its position in the + label stack (see Section 4.2). + + o The setting of the TC field of the GAL is application specific. + See Section 4.2.1 for definition and processing rules. + + LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards + the targeted destination. + + + + + + + +Bocci, et al. Standards Track [Page 11] + +RFC 5586 G-ACh and GAL June 2009 + + + Note: This is because once a G-ACh packet has been sent on an LSP, + no node has visibility of it unless the LSP label TTL expires or + the GAL is exposed when the LSP label is popped. If this is at + the targeted destination, for example, indicated by an address in + an ACH TLV, then processing can proceed as specified below. If + this is not the targeted destination, but the node has agreed to + process packets on that ACH channel, then the processing applied + to the packet is out of scope of this document. + + Upon reception of the labeled packet, the targeted destination, after + having checked both the LSP Label and GAL LSEs fields, SHOULD pass + the whole packet to the appropriate processing entity. + +4.2.1.2. MPLS Section + + The following figure (Figure 7) depicts an example of an MPLS + Section. + + +---+ +---+ + | A |-------------| Z | + +---+ +---+ + + Figure 7: Maintenance over an MPLS Section + + With regard to the MPLS Section, a G-ACh exists between A and Z. + Only A and Z can insert, extract, or process packets on this G-ACh. + + The following figure (Figure 8) depicts the format of a G-ACh packet + when used for an MPLS Section. The GAL MAY provide the exception + mechanism for a control channel in its own right without being + associated with a specific LSP, thus providing maintenance-related + communications across a specific link interconnecting two LSRs. In + this case, the GAL is the only label in the stack. + + + + + + + + + + + + + + + + + + +Bocci, et al. Standards Track [Page 12] + +RFC 5586 G-ACh and GAL June 2009 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | GAL | TC |S| TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACH TLV Header (if present) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ~ + ~ Zero or more ACH TLVs ~ + ~ (if present) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ~ + ~ G-ACh message ~ + ~ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: G-ACh Packet Format for an MPLS Section + + To send a G-ACh message on a control channel associated to the + Section, the head-end LSR (A) of the Section generates a G-ACh + message, to which it MAY prepend an ACH TLV Header and appropriate + ACH TLVs. Next, the LSR adds an ACH. Finally, it pushes a GAL LSE. + + o The TTL field of the GAL MUST be set to at least 1. The exact + value of the TTL is application specific. See Section 4.2.1 for + definition and processing rules. + + o The S bit of the GAL MUST be set according to its position in the + label stack. (see Section 4.2). + + o The setting of the TC field of the GAL is application specific. + See Section 4.2.1 for definition and processing rules. + + Intermediate nodes of the MPLS Section MUST NOT modify the G-ACh + message, the ACH and the GAL towards the tail-end LSR (Z). Upon + reception of the G-ACh packet, the tail-end LSR (Z), after having + checked the GAL LSE fields, SHOULD pass the whole packet to the + appropriate processing entity. + +4.3. Relationship with RFC 3429 + + RFC 3429 [RFC3429] describes the assignment of one of the reserved + label values, defined in RFC 3032 [RFC3032], to the "OAM Alert Label" + that is used by user-plane MPLS OAM functions for the identification + of MPLS OAM packets. The value of 14 is used for that purpose. + + + + +Bocci, et al. Standards Track [Page 13] + +RFC 5586 G-ACh and GAL June 2009 + + + Both this document and RFC 3429 [RFC3429] therefore describe the + assignment of reserved label values for similar purposes. The + rationale for the assignment of a new reserved label can be + summarized as follows: + + o Unlike the mechanisms described and referenced in RFC 3429 + [RFC3429], G-ACh messages will not reside immediately after the + GAL but instead behind the ACH, which itself resides after the + bottom of the label stack. + + o The set of maintenance functions potentially operated in the + context of the G-ACh is wider than the set of OAM functions + referenced in RFC 3429 [RFC3429]. + + o It has been reported that there are existing implementations and + running deployments using the "OAM Alert Label" as described in + RFC 3429 [RFC3429]. It is therefore not possible to modify the + "OAM Alert Label" allocation, purpose, or usage. Nevertheless, it + is RECOMMENDED that no further OAM extensions based on "OAM Alert + Label" (Label 14) usage be specified or developed. + +5. Compatibility + + Procedures for handling a packet received with an invalid incoming + label are specified in RFC 3031 [RFC3031]. + + An LER, LSR, or PE MUST discard received associated channel packets + on which all of the MPLS or PW labels have been popped if any one of + the following conditions is true: + + o It is not capable of processing packets on the Channel Type + indicated by the ACH of the received packet. + + o It has not, through means outside the scope of this document, + indicated to the sending LSR, LER, or PE that it will process + associated channel packets on the Channel Type indicated by the + ACH of the received packet. + + o The packet is received on an Experimental Channel Type that is + locally disabled. + + o If the ACH was indicated by the presence of a GAL, and the first + nibble of the ACH of the received packet is not 0001b. + + o The ACH version is not recognized. + + + + + + +Bocci, et al. Standards Track [Page 14] + +RFC 5586 G-ACh and GAL June 2009 + + + In addition, the LER, LSR, or PE MAY increment an error counter and + MAY also issue a system and/or Simple Network Management Protocol + (SNMP) notification. + +6. Congestion Considerations + + The congestion considerations detailed in RFC 5085 [RFC5085] apply. + +7. Major Contributing Authors + + The editors would like to thank George Swallow, David Ward, and Rahul + Aggarwal who made a major contribution to the development of this + document. + + George Swallow + Cisco Systems + Email: swallow@cisco.com + + David Ward + Cisco Systems + Email: dward@cisco.com + + Rahul Aggarwal + Juniper Networks + Email: rahul@juniper.net + +8. Acknowledgments + + The editors gratefully acknowledge the contributions of Sami Boutros, + Italo Busi, Marc Lasserre, Lieven Levrau, and Siva Sivabalan. + + The authors would also like to thank Malcolm Betts, ITU-T Study Group + 15, and all members of the teams (the Joint Working Team, the MPLS + Interoperability Design Team in IETF and the MPLS-TP Ad Hoc Team in + ITU-T) involved in the definition and specification of the MPLS + Transport Profile. + +9. Security Considerations + + The security considerations for the associated control channel are + described in RFC 4385 [RFC4385]. Further security considerations + MUST be described in the relevant associated channel type + specification. + + RFC 5085 [RFC5085] provides data plane related security + considerations. These also apply to a G-ACh, whether the alert + mechanism uses a GAL or only an ACH. + + + + +Bocci, et al. Standards Track [Page 15] + +RFC 5586 G-ACh and GAL June 2009 + + +10. IANA Considerations + + IANA allocated label value 13 to the GAL from the pool of reserved + labels in the "Multiprotocol Label Switching Architecture (MPLS) + Label Values" registry. + + Channel Types for the Associated Channel Header are allocated from + the IANA "PW Associated Channel Type" registry [RFC4446]. The PW + Associated Channel Type registry is currently allocated based on the + IETF consensus process (termed "IETF Review" in [RFC5226]). This + allocation process was chosen based on the consensus reached in the + PWE3 working group that pseudowire associated channel mechanisms + should be reviewed by the IETF and only those that are consistent + with the PWE3 architecture and requirements should be allocated a + code point. + + However, a requirement has emerged (see [OAM-REQ]) to allow for + optimizations or extensions to OAM and other control protocols + running in an associated channel to be experimented without resorting + to the IETF standards process, by supporting experimental code + points. This would prevent code points used for such functions from + being used from the range allocated through the IETF standards and + thus protects an installed base of equipment from potential + inadvertent overloading of code points. In order to support this + requirement, IANA has changed the code point allocation scheme for + the PW Associated Channel Type be changed as follows: + + 0 - 32751 : IETF Review + + 32760 - 32767 : Experimental + + Code points in the experimental range MUST be used according to the + guidelines of RFC 3692 [RFC3692]. Functions using experimental G-ACh + code points MUST be disabled by default. The Channel Type value used + for a given experimental OAM function MUST be configurable, and care + MUST be taken to ensure that different OAM functions that are not + inter-operable are configured to use different Channel Type values. + + The PW Associated Channel Type registry has been updated to include a + column indicating whether the ACH is followed by a ACH TLV header + (Yes/No). There are two ACH Channel Type code-points currently + assigned and in both cases no ACH TLV header is used. Thus, the new + format of the PW Channel Type registry is: + + + + + + + + +Bocci, et al. Standards Track [Page 16] + +RFC 5586 G-ACh and GAL June 2009 + + + Registry: + Value Description TLV Follows Reference + ----- ---------------------------- ----------- --------- + 0x21 ACH carries an IPv4 packet No [RFC4385] + 0x57 ACH carries an IPv6 packet No [RFC4385] + + Figure 9: PW Channel Type Registry + + IANA created a new registry called the Associated Channel Header TLV + Registry. The allocation policy for this registry is IETF review. + This registry MUST record the following information. There are no + initial entries. + + Name Type Length Description Reference + (octets) + + Figure 10: ACH TLV Registry + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, January 2001. + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, January 2001. + + [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing + in Multi-Protocol Label Switching (MPLS) Networks", + RFC 3443, January 2003. + + [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, January 2004. + + [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. + + [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to + Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. + + + + + + +Bocci, et al. Standards Track [Page 17] + +RFC 5586 G-ACh and GAL June 2009 + + + [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit + Connectivity Verification (VCCV): A Control Channel for + Pseudowires", RFC 5085, December 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label + Switching (MPLS) Label Stack Entry: "EXP" Field Renamed + to "Traffic Class" Field", RFC 5462, February 2009. + +11.2. Informative References + + [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, + "BFD For MPLS LSPs", Work in Progress, June 2008. + + [BFD-VCCV] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding + Detection (BFD) for the Pseudowire Virtual Circuit + Connectivity Verification (VCCV)", Work in Progress, + May 2009. + + [G805] International Telecommunication Union, "Generic + Functional Architecture of Transport Networks", ITU- + T G.805, March 2000. + + [MPLS-TP] Bocci, M., Bryant, S., and L. Levrau, "A Framework for + MPLS in Transport Networks", Work in Progress, + November 2008. + + [OAM-REQ] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., + "Requirements for OAM in MPLS Transport Networks", Work + in Progress, March 2009. + + [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for + Multiprotocol Label Switching Architecture (MPLS) + Operation and Maintenance (OAM) Functions", RFC 3429, + November 2002. + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + February 2006. + + [TP-REQ] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., + Ed., Sprecher, N., and S. Ueno, "MPLS-TP Requirements", + Work in Progress, May 2009. + + + + + +Bocci, et al. Standards Track [Page 18] + +RFC 5586 G-ACh and GAL June 2009 + + +Authors' Addresses + + Matthew Bocci (editor) + Alcatel-Lucent + Voyager Place, Shoppenhangers Road + Maidenhead, Berks SL6 2PJ + UK + + EMail: matthew.bocci@alcatel-lucent.com + + + Martin Vigoureux (editor) + Alcatel-Lucent + Route de Villejust + Nozay, 91620 + France + + EMail: martin.vigoureux@alcatel-lucent.com + + + Stewart Bryant (editor) + Cisco Systems + + EMail: stbryant@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bocci, et al. Standards Track [Page 19] + |