summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7708.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7708.txt')
-rw-r--r--doc/rfc/rfc7708.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc7708.txt b/doc/rfc/rfc7708.txt
new file mode 100644
index 0000000..cba6c6b
--- /dev/null
+++ b/doc/rfc/rfc7708.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Nadeau
+Request for Comments: 7708 Brocade
+Category: Standards Track L. Martini
+ISSN: 2070-1721 S. Bryant
+ Cisco Systems
+ November 2015
+
+
+ Using a Generic Associated Channel Label
+ as a Virtual Circuit Connectivity Verification Channel Indicator
+
+Abstract
+
+ The Virtual Circuit Connectivity Verification (VCCV) protocol
+ specified in RFC 5085 provides a control channel (CC) that is
+ associated with a pseudowire (PW). This document specifies an
+ additional VCCV control channel type to be used with pseudowires that
+ do not use the PW Control Word and that are carried over an MPLS
+ network. This new VCCV CC type uses the Generic Associated Channel
+ Label defined in RFC 5586 to distinguish VCCV packets from packets
+ carrying user data. This new VCCV CC type introduces compatibility
+ with the method of MPLS Label Switched Path Operations,
+ Administration, and Maintenance (OAM) identification, particularly in
+ MPLS Transport Profile (MPLS-TP) networks (RFC 5921).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7708.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al. Standards Track [Page 1]
+
+RFC 7708 GAL as a VCCV Channel November 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
+ 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
+ 3. Type 4 MPLS VCCV Control Channel Type . . . . . . . . . . . . 3
+ 4. FAT PWs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Multi-Segment Pseudowires . . . . . . . . . . . . . . . . . . 5
+ 6. VCCV Capability Advertisement . . . . . . . . . . . . . . . . 5
+ 7. Manageability Considerations . . . . . . . . . . . . . . . . 6
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 9.1. MPLS VCCV Control Channel (CC) Type 4 . . . . . . . . . . 7
+ 9.2. LDP Status Code . . . . . . . . . . . . . . . . . . . . . 7
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 8
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
+
+1. Introduction
+
+ The Virtual Circuit Connectivity Verification (VCCV) protocol is
+ specified in RFC 5085 [RFC5085]. This document specifies a new VCCV
+ control channel (VCCV CC) type to be used with pseudowires (PWs)
+ carried over an MPLS network that do not use the PW Control Word (CW)
+ [RFC4385]. This new VCCV CC type uses the Generic Associated Channel
+ Label (GAL) [RFC5586] to distinguish VCCV packets from packets
+ carrying user data. This new VCCV CC type provides compatibility
+ with the method of MPLS Label Switched Path (LSP) Operations,
+ Administration, and Maintenance (OAM) message identification, as used
+ in MPLS Transport Profile (MPLS-TP) networks [RFC5921].
+
+
+
+
+
+Nadeau, et al. Standards Track [Page 2]
+
+RFC 7708 GAL as a VCCV Channel November 2015
+
+
+ VCCV currently specifies three CC types. VCCV CC Type 1 uses the PW
+ Control Word (CW) to distinguish VCCV packets from packets carrying
+ user data. VCCV CC Types 2 and 3 require IP encapsulation for OAM
+ packets. This was not an issue when [RFC5085] was designed, but it
+ is in conflict with the design goals of MPLS-TP [RFC5921], which do
+ not otherwise require the availability of IP. VCCV CC Type 2 is not
+ applicable to Multi-Segment PWs (MS-PWs) [RFC6073]. A MS-PW
+ operating without the CW therefore has to use VCCV CC Type 3, which
+ identifies VCCV packets on the basis of Time to Live (TTL) expiry.
+ Whilst less of an issue with a single segment PW (SS-PW), on an MS-PW
+ this requires accurately setting the TTL for expiry at the egress
+ Terminating Provider Edge (T-PE) [RFC6073]. In the event of an error
+ in the setting of the PW Label Stack Entry (LSE) TTL, VCCV packets
+ will not be received by the Terminating Provider Edge (T-PE) and may
+ leak into the attachment circuit [RFC6073]. The new VCCV CC type
+ defined in this specification addresses these problems for PWs that
+ do not use the CW.
+
+ Note that mandating that PWs use the PW CW is not a viable way to
+ address this issue. This is because:
+
+ o PWs without the CW are already widely deployed.
+
+ o There is a significant deployment of existing hardware that does
+ not support usage of the PW CW for some PW types.
+
+ o Some operators are concerned that the inclusion of the PW CW will
+ increase the PW packet size.
+
+2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+3. Type 4 MPLS VCCV Control Channel Type
+
+ When the PW CW is not used, the Type 4 MPLS VCCV Control Channel (CC)
+ type defined in this section MAY be used. This is referred to as
+ VCCV CC Type 4 throughout the rest of this of this document. VCCV CC
+ Type 4 uses the encapsulation shown in Figure 1 in which the presence
+ of a GAL at the end of the MPLS label stack indicates that the packet
+ carries a VCCV message.
+
+
+
+
+
+
+
+Nadeau, et al. Standards Track [Page 3]
+
+RFC 7708 GAL as a VCCV Channel November 2015
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PW LSE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | GAL LSE |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 1|Version| Reserved | Channel Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ ~ VCCV Message Body ~
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1
+
+ The VCCV message body is preceded by a Generic Associated Channel
+ Header, as defined in [RFC5586], in which the Channel Type identifies
+ the type and format of the OAM message carried in the VCCV message
+ body.
+
+ The GAL LSE MUST contain the GAL reserved label as defined in
+ [RFC5586].
+
+ The PW LSE is constructed according to the existing procedures that
+ apply to the type of pseudowire that is in use.
+
+ Where the LSP used by the PW is subject to Equal-Cost Multipath
+ (ECMP) load balancing, a problem arises if any LSR on that LSP treats
+ special-purpose labels as ordinary labels in its ECMP selection
+ method. In these circumstances, the inclusion of a GAL following the
+ PW LSE can cause the OAM packet to take a different path through the
+ network than the corresponding PW data packets. If the LSP traverses
+ such equipment and this behaviour is not acceptable, then an
+ alternative VCCV type needs to be used. The requirement to not
+ include special-purpose labels in the load-balancing decision is
+ described in "MPLS Forwarding Compliance and Performance
+ Requirements" [RFC7325]. For equipment that conforms to this, the
+ VCCV type 4 traffic will follow the corresponding PW data packets.
+
+4. FAT PWs
+
+ [RFC6391] specifies that when the flow-aware transport (FAT) of
+ pseudowires over an MPLS packet switched network has been signalled
+ or configured, the Flow LSE MUST be present. It further specifies
+ that "the flow label MUST NOT be an MPLS reserved label (values in
+ the range 0..15) [RFC3032]", and that "If a flow LSE is present, it
+ MUST be checked to determine whether it carries a reserved label. If
+
+
+
+Nadeau, et al. Standards Track [Page 4]
+
+RFC 7708 GAL as a VCCV Channel November 2015
+
+
+ it is a reserved label, the packet is processed according to the
+ rules associated with that reserved label; otherwise, the LSE is
+ discarded."
+
+ This document specifies that if the flow-aware transport of
+ pseudowires over an MPLS packet switched network has been signalled
+ or configured, then the presence of VCCV message is indicated by the
+ use of a GAL in place of the flow LSE.
+
+ This is consistent with [RFC6391], and the packet structure is
+ identical to that shown in Figure 1.
+
+ Flow LSEs are inserted into a PW label stack in order to enable the
+ distribution of the PW traffic among multiple equal-cost MPLS paths.
+ The use of GAL in place of the flow label will cause all OAM packets
+ to take exactly one of the possible paths through the network. As
+ noted in Section 3, the ECMP selection method may result in the path
+ taken by the OAM packets being different from the path taken by any
+ of the actual traffic flows. If this is not acceptable, then an
+ alternative VCCV type needs be used.
+
+5. Multi-Segment Pseudowires
+
+ When using VCCV CC Type 4 for MS-PWs, a PE transmitting the VCCV
+ packet to a Switching PE (S-PE) MUST set the TTL to the appropriate
+ value to expire at that S-PE. An S-PE that supports this
+ specification MUST inspect PW packets that are received as a result
+ of TTL expiry, and determine whether a GAL follows the PW LSE. If a
+ GAL is present, the S-PE then processes the VCCV packet.
+
+ An S-PE that does not support this specification would be expected to
+ reject as malformed a VCCV CC Type 4 packet that was received. This
+ is because the S-PE would expect the PW LSE to be the bottom of stack
+ (the non-FAT case) and for the LSE at the bottom of stack not to be a
+ reserved label (both the FAT and the non-FAT cases). An S-PE that
+ did not make this reserved label check would then find that the first
+ nibble following the label stack was 0x1 and not the expected start
+ of an IP packet. Thus, it would be expected to also reject the
+ packet. This update to the behaviour of S-PEs is therefore backwards
+ compatible.
+
+6. VCCV Capability Advertisement
+
+ The VCCV capability advertisement MUST match the C-bit setting that
+ is advertised in the PW FEC element [RFC4447]. If the C-bit is set,
+ indicating the use of the PW CW, then VCCV CC Type 4 MUST NOT be
+ advertised. If the C-bit is not set, indicating that the PW CW is
+ not in use, then equipment supporting this specification MUST
+
+
+
+Nadeau, et al. Standards Track [Page 5]
+
+RFC 7708 GAL as a VCCV Channel November 2015
+
+
+ advertise VCCV CC Type 4. Advertisement of VCCV CC Type 1 and
+ advertisement of VCCV CC Type 4 are therefore mutually exclusive.
+
+ A PE supporting VCCV CC Type 4 MAY advertise other VCCV CC types as
+ defined in [RFC5085] .
+
+ If the remote PE supports VCCV CC Type 4, and the PW CW is not in
+ use, then for cases where multiple CC Types are advertised, the
+ following precedence rules apply when choosing which CC Type to use:
+
+ 1. Type 4: GAL VCCV Control Channel.
+
+ 2. Type 2: MPLS Router Alert Label.
+
+ 3. Type 3: MPLS PW Label with TTL == 1.
+
+ If the remote PE finds that VCCV CC Types 1 and 4 are both
+ advertised, or that C-bit is set and VCCV CC Type 4 is advertised,
+ then it should report the error to the operator through the
+ management interface in use, and send a Label Release Message with a
+ status code "VCCV Type Error".
+
+7. Manageability Considerations
+
+ Whilst the introduction of this additional VCCV CC type increases the
+ number of VCCV CC types that the operator needs to manage, it
+ addresses the issues with VCCV CC Types 2 and 3 described in
+ Section 1.
+
+ In the event of a misconfiguration of this VCCV CC type, the PW is
+ taken out of service and the operator advised as described in
+ Section 6.
+
+ Attention is drawn to the possible absence of fate sharing between PW
+ data packets and VCCV CC Type 4 packets described in Section 3 and
+ Section 4.
+
+8. Security Considerations
+
+ This document does not by itself raise any new security
+ considerations beyond those described in [RFC5085] and [RFC6073].
+ [RFC6073] provides detailed operational procedures that can be used
+ to verify the MS-PW connectivity. In addition, the procedure
+ specified in this document eliminates the possibility of packet
+ leaking that can occur with VCCV Type 3.
+
+
+
+
+
+
+Nadeau, et al. Standards Track [Page 6]
+
+RFC 7708 GAL as a VCCV Channel November 2015
+
+
+9. IANA Considerations
+
+9.1. MPLS VCCV Control Channel (CC) Type 4
+
+ IANA has assigned a new bit from the MPLS VCCV Control Channel (CC)
+ Types registry in the "Pseudowire Name Spaces (PWE3)" registry in
+ order to identify VCCV type 4.
+
+ MPLS VCCV Control Channel (CC) Types
+
+ Bit (Value) Description Reference
+ ============ =========== ==================
+ Bit 3 (0x08) Type 4: GAL RFC 7708
+
+9.2. LDP Status Code
+
+ IANA has assigned a new Status Code from the "Label Distribution
+ Protocol (LDP) Parameters" registry:
+
+ Status Code Name Space
+ Range/Value E Description Reference
+ =========== = =============== =========
+ 0x00000035 0 VCCV Type Error RFC 7708
+
+10. References
+
+10.1. Normative References
+
+ [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>.
+
+ [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, DOI 10.17487/RFC4385,
+ February 2006, <http://www.rfc-editor.org/info/rfc4385>.
+
+ [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
+ G. Heron, "Pseudowire Setup and Maintenance Using the
+ Label Distribution Protocol (LDP)", RFC 4447,
+ DOI 10.17487/RFC4447, April 2006,
+ <http://www.rfc-editor.org/info/rfc4447>.
+
+ [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
+ Circuit Connectivity Verification (VCCV): A Control
+ Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
+ December 2007, <http://www.rfc-editor.org/info/rfc5085>.
+
+
+
+Nadeau, et al. Standards Track [Page 7]
+
+RFC 7708 GAL as a VCCV Channel November 2015
+
+
+ [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+ "MPLS Generic Associated Channel", RFC 5586,
+ DOI 10.17487/RFC5586, June 2009,
+ <http://www.rfc-editor.org/info/rfc5586>.
+
+ [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
+ Aissaoui, "Segmented Pseudowire", RFC 6073,
+ DOI 10.17487/RFC6073, January 2011,
+ <http://www.rfc-editor.org/info/rfc6073>.
+
+ [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
+ Regan, J., and S. Amante, "Flow-Aware Transport of
+ Pseudowires over an MPLS Packet Switched Network",
+ RFC 6391, DOI 10.17487/RFC6391, November 2011,
+ <http://www.rfc-editor.org/info/rfc6391>.
+
+10.2. Informative References
+
+ [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
+ L., and L. Berger, "A Framework for MPLS in Transport
+ Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
+ <http://www.rfc-editor.org/info/rfc5921>.
+
+ [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
+ and C. Pignataro, "MPLS Forwarding Compliance and
+ Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
+ August 2014, <http://www.rfc-editor.org/info/rfc7325>.
+
+Acknowledgments
+
+ The authors wish to thank Alexander (Sasha) Vainshtein for his
+ proposal to make the GAL and Flow labels mutually exclusive. This
+ proposal led to a significant simplification of this design. The
+ authors also thank Sasha, Matthew Bocci, Loa Andersson, and Deborah
+ Brungard for their review comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al. Standards Track [Page 8]
+
+RFC 7708 GAL as a VCCV Channel November 2015
+
+
+Authors' Addresses
+
+ Thomas D. Nadeau
+ Brocade
+
+ Email: tnadeau@lucidvision.com
+
+
+ Luca Martini
+ Cisco Systems
+
+ Email: lmartini@cisco.com
+
+
+ Stewart Bryant
+ Cisco Systems
+
+ Email: stewart.bryant@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al. Standards Track [Page 9]
+