--- 1/draft-smack-mpls-rfc4379bis-05.txt 2015-10-09 12:23:01.132094996 -0700 +++ 2/draft-smack-mpls-rfc4379bis-06.txt 2015-10-09 12:23:01.444102575 -0700 @@ -1,22 +1,22 @@ Network Working Group C. Pignataro Internet-Draft N. Kumar -Obsoletes: 4379 (if approved) Cisco +Obsoletes: 4379, 6829 (if approved) Cisco Intended status: Standards Track S. Aldrin -Expires: April 5, 2016 Google +Expires: April 8, 2016 Google M. Chen Huawei - October 3, 2015 + October 6, 2015 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures - draft-smack-mpls-rfc4379bis-05 + draft-smack-mpls-rfc4379bis-06 Abstract This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. @@ -30,92 +30,94 @@ 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 April 5, 2016. + This Internet-Draft will expire on April 8, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Structure of This Document . . . . . . . . . . . . . . . 4 1.3. Contributors . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Scope of RFC4379bis work . . . . . . . . . . . . . . . . 4 1.5. ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Use of Address Range 127/8 . . . . . . . . . . . . . . . 6 - 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 12 - 3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . 14 - 3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . 14 - 3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . 14 - 3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . 15 - 3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . 15 - 3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . 16 - 3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . 17 - 3.2.8. FEC 128 Pseudowire (Deprecated) . . . . . . . . . . 17 - 3.2.9. FEC 128 Pseudowire (Current) . . . . . . . . . . . . 18 - 3.2.10. FEC 129 Pseudowire . . . . . . . . . . . . . . . . . 19 - 3.2.11. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . 20 - 3.2.12. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . 20 - 3.2.13. Generic IPv4 Prefix . . . . . . . . . . . . . . . . 21 - 3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . 21 - 3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . 22 - 3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 22 - 3.3.1. Multipath Information Encoding . . . . . . . . . . . 26 - 3.3.2. Downstream Router and Interface . . . . . . . . . . 28 - 3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . 29 - 3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 29 - 3.6. Interface and Label Stack . . . . . . . . . . . . . . . 29 - 3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 31 - 3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 31 - 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . 31 - 4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . 32 - 4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . 33 - 4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 33 - 4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 34 - 4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 40 - 4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 41 - 4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 42 - 4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . 42 - 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . 42 - 5. Security Considerations . . . . . . . . . . . . . . . . . . 43 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 - 6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 44 - 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 47 - 8.2. Informative References . . . . . . . . . . . . . . . . . 48 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 + 3.2.1. LDP IPv4 Prefix . . . . . . . . . . . . . . . . . . . 14 + 3.2.2. LDP IPv6 Prefix . . . . . . . . . . . . . . . . . . . 14 + 3.2.3. RSVP IPv4 LSP . . . . . . . . . . . . . . . . . . . . 14 + 3.2.4. RSVP IPv6 LSP . . . . . . . . . . . . . . . . . . . . 15 + 3.2.5. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 15 + 3.2.6. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 16 + 3.2.7. L2 VPN Endpoint . . . . . . . . . . . . . . . . . . . 17 + 3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) . . . . . . . 17 + 3.2.9. FEC 128 Pseudowire - IPv4 (Current) . . . . . . . . . 18 + 3.2.10. FEC 129 Pseudowire - IPv4 . . . . . . . . . . . . . . 19 + 3.2.11. BGP Labeled IPv4 Prefix . . . . . . . . . . . . . . . 20 + 3.2.12. BGP Labeled IPv6 Prefix . . . . . . . . . . . . . . . 20 + 3.2.13. Generic IPv4 Prefix . . . . . . . . . . . . . . . . . 21 + 3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . . 21 + 3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . . 22 + 3.2.16. FEC 128 Pseudowire - IPv6 . . . . . . . . . . . . . . 22 + 3.2.17. FEC 129 Pseudowire - IPv6 . . . . . . . . . . . . . . 23 + 3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 24 + 3.3.1. Multipath Information Encoding . . . . . . . . . . . 27 + 3.3.2. Downstream Router and Interface . . . . . . . . . . . 29 + 3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 30 + 3.6. Interface and Label Stack . . . . . . . . . . . . . . . . 31 + 3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 32 + 3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 32 + 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 33 + 4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . . 33 + 4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . . 34 + 4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 34 + 4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 35 + 4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 41 + 4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 42 + 4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 43 + 4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . . 43 + 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . . 44 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 44 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 + 6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 46 + 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 48 + 8.2. Informative References . . . . . . . . . . . . . . . . . 49 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply", and mechanisms for transporting the echo reply. The first part aims at providing enough information to check correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane, and @@ -190,31 +192,33 @@ including: 1. Updates to all references and citations. Obsoleted RFCs 2434, 2030, and 3036 are respectively replaced with RFCs 5226, 5905, and 5036. Additionally, these three documents published as RFCs: RFCs 4447, 5085, and 4761. 2. Incorporate all outstanding Errata. These include Erratum with IDs: 108, 1418, 1714, 1786, 3399, 742, and 2978. 3. Replace EXP with Traffic Class (TC), based on the update from RFC 5462. + 4. Incorporate the updates from RFC 6829, adding the PW FECs + advertised over IPv6. 1.5. ToDo This section should be empty, and removed, prior to publication. ToDos: 1. Evaluation of which of the RFCs that updated RFC 4379 need to be incorporated into this 4379bis document. Specifically, these - RFCs updated RFC 4379: 6424, 6425, 6426, 6829, 7506, and 7537. - RFCs that updated RFC 4379 and are incorporated into this - 4379bis, will be Obsoleted by 4379bis. + RFCs updated RFC 4379: 6424, 6425, 6426, 7506, and 7537. RFCs + that updated RFC 4379 and are incorporated into this 4379bis, + will be Obsoleted by 4379bis. 2. Review IANA Allocations 2. Motivation When an LSP fails to deliver user traffic, the failure cannot always be detected by the MPLS control plane. There is a need to provide a tool that would enable users to detect such traffic "black holes" or misrouting within a reasonable period of time, and a mechanism to isolate faults. @@ -559,28 +563,30 @@ Sub-Type Length Value Field -------- ------ ----------- 1 5 LDP IPv4 prefix 2 17 LDP IPv6 prefix 3 20 RSVP IPv4 LSP 4 56 RSVP IPv6 LSP 5 Not Assigned 6 13 VPN IPv4 prefix 7 25 VPN IPv6 prefix 8 14 L2 VPN endpoint - 9 10 "FEC 128" Pseudowire (deprecated) - 10 14 "FEC 128" Pseudowire - 11 16+ "FEC 129" Pseudowire + 9 10 "FEC 128" Pseudowire - IPv4 (deprecated) + 10 14 "FEC 128" Pseudowire - IPv4 + 11 16+ "FEC 129" Pseudowire - IPv4 12 5 BGP labeled IPv4 prefix 13 17 BGP labeled IPv6 prefix 14 5 Generic IPv4 prefix 15 17 Generic IPv6 prefix 16 4 Nil FEC + 24 38 "FEC 128" Pseudowire - IPv6 + 25 40+ "FEC 129" Pseudowire - IPv6 Other FEC Types will be defined as needed. Note that this TLV defines a stack of FECs, the first FEC element corresponding to the top of the label stack, etc. An MPLS echo request MUST have a Target FEC Stack that describes the FEC Stack being tested. For example, if an LSR X has an LDP mapping [RFC5036] for 192.168.1.1 (say, label 1001), then to verify that label 1001 does indeed reach an egress LSR that announced this prefix @@ -776,107 +782,107 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's VE ID | Receiver's VE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encapsulation Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -3.2.8. FEC 128 Pseudowire (Deprecated) +3.2.8. FEC 128 Pseudowire - IPv4 (Deprecated) FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 32-bit connection ID. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below termed encapsulation type with the high-order bit set to zero. Both of these fields are treated in this protocol as opaque values. When an FEC 128 is encoded in a label stack, the following format is - used. The value field consists of the remote PE address (the + used. The value field consists of the remote PE IPv4 address (the destination address of the targeted LDP session), the PW ID, and the encapsulation type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Remote PE Address | + | Remote PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This FEC is deprecated and is retained only for backward compatibility. Implementations of LSP ping SHOULD accept and process this TLV, but SHOULD send LSP ping echo requests with the new TLV (see next section), unless explicitly configured to use the old TLV. An LSR receiving this TLV SHOULD use the source IP address of the LSP echo request to infer the sender's PE address. -3.2.9. FEC 128 Pseudowire (Current) +3.2.9. FEC 128 Pseudowire - IPv4 (Current) FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID (Pseudowire ID) and PW Type (Pseudowire Type). A PW ID is a non-zero 32-bit connection ID. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below termed encapsulation type with the high-order bit set to zero. Both of these fields are treated in this protocol as opaque values. When matching these field to the local FEC information, the match MUST be exact. When an FEC 128 is encoded in a label stack, the following format is - used. The value field consists of the sender's PE address (the - source address of the targeted LDP session), the remote PE address - (the destination address of the targeted LDP session), the PW ID, and - the encapsulation type as follows: + used. The value field consists of the sender's PE IPv4 address (the + source address of the targeted LDP session), the remote PE IPv4 + address (the destination address of the targeted LDP session), the PW + ID, and the encapsulation type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Sender's PE Address | + | Sender's PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Remote PE Address | + | Remote PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -3.2.10. FEC 129 Pseudowire +3.2.10. FEC 129 Pseudowire - IPv4 FEC 129 (0x81) and the terms PW Type, Attachment Group Identifier (AGI), Attachment Group Identifier Type (AGI Type), Attachment Individual Identifier Type (AII Type), Source Attachment Individual Identifier (SAII), and Target Attachment Individual Identifier (TAII) are defined in [RFC4447]. The PW Type is a 15-bit number indicating the encapsulation type. It is carried right justified in the field below PW Type with the high-order bit set to zero. All the other fields are treated as opaque values and copied directly from the FEC 129 format. All of these values together uniquely define the FEC within the scope of the LDP session identified by the source and - remote PE addresses. + remote PE IPv4 addresses. When an FEC 129 is encoded in a label stack, the following format is used. The Length of this TLV is 16 + AGI length + SAII length + TAII length. Padding is used to make the total length a multiple of 4; the length of the padding is not included in the Length field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Sender's PE Address | + | Sender's PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Remote PE Address | + | Remote PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Type | AGI Type | AGI Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | SAII Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (continued) ~ | | @@ -975,20 +981,93 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label is the actual label value inserted in the label stack; the MBZ fields MUST be zero when sent and ignored on receipt. +3.2.16. FEC 128 Pseudowire - IPv6 + + The FEC 128 Pseudowire IPv6 sub-TLV has a structure consistent with + the FEC 128 Pseudowire IPv4 sub-TLV as described in Section 3.2.9. + The value field consists of the Sender's PE IPv6 address (the source + address of the targeted LDP session), the remote PE IPv6 address (the + destination address of the targeted LDP session), the PW ID, and the + encapsulation type 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Sender's PE IPv6 Address ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Remote PE IPv6 Address ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PW ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PW Type | Must Be Zero | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sender's PE IPv6 Address: The source IP address of the target IPv6 + LDP session. 16 octets. + + Remote PE IPv6 Address: The destination IP address of the target IPv6 + LDP session. 16 octets. + + PW ID: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9. + + PW Type: Same as FEC 128 Pseudowire IPv4 in Section 3.2.9. + +3.2.17. FEC 129 Pseudowire - IPv6 + + The FEC 129 Pseudowire IPv6 sub-TLV has a structure consistent with + the FEC 129 Pseudowire IPv4 sub-TLV as described in Section 3.2.10. + When an FEC 129 is encoded in a label stack, the following format is + used. The length of this TLV is 40 + AGI (Attachment Group + Identifier) length + SAII (Source Attachment Individual Identifier) + length + TAII (Target Attachment Individual Identifier) length. + Padding is used to make the total length a multiple of 4; the length + of the padding is not included in the Length field. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Sender's PE IPv6 Address ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Remote PE IPv6 Address ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PW Type | AGI Type | AGI Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ AGI Value ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AII Type | SAII Length | SAII Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ SAII Value (continued) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AII Type | TAII Length | TAII Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ TAII Value (continued) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TAII (cont.) | 0-3 octets of zero padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sender's PE IPv6 Address: The source IP address of the target IPv6 + LDP session. 16 octets. + + Remote PE IPv6 Address: The destination IP address of the target IPv6 + LDP session. 16 octets. + + The other fields are the same as FEC 129 Pseudowire IPv4 in + Section 3.2.10. + 3.3. Downstream Mapping The Downstream Mapping object is a TLV that MAY be included in an echo request message. Only one Downstream Mapping object may appear in an echo request. The presence of a Downstream Mapping object is a request that Downstream Mapping objects be included in the echo reply. If the replying router is the destination of the FEC, then a Downstream Mapping TLV SHOULD NOT be included in the echo reply. Otherwise the replying router SHOULD include a Downstream Mapping object for each interface over which this FEC could be forwarded. @@ -2093,28 +2169,30 @@ ---- -------- ----------- 1 Target FEC Stack 1 LDP IPv4 prefix 2 LDP IPv6 prefix 3 RSVP IPv4 LSP 4 RSVP IPv6 LSP 5 Not Assigned 6 VPN IPv4 prefix 7 VPN IPv6 prefix 8 L2 VPN endpoint - 9 "FEC 128" Pseudowire (Deprecated) - 10 "FEC 128" Pseudowire - 11 "FEC 129" Pseudowire + 9 "FEC 128" Pseudowire - IPv4 (Deprecated) + 10 "FEC 128" Pseudowire - IPv4 + 11 "FEC 129" Pseudowire - IPv4 12 BGP labeled IPv4 prefix 13 BGP labeled IPv6 prefix 14 Generic IPv4 prefix 15 Generic IPv6 prefix 16 Nil FEC + 24 "FEC 128" Pseudowire - IPv6 + 25 "FEC 129" Pseudowire - IPv6 2 Downstream Mapping 3 Pad 4 Not Assigned 5 Vendor Enterprise Number 6 Not Assigned 7 Interface and Label Stack 8 Not Assigned 9 Errored TLVs Any value The TLV not understood 10 Reply TOS Byte @@ -2126,111 +2204,118 @@ This document is the outcome of many discussions among many people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter, Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani Aggarwal, and Vanson Lim. The description of the Multipath Information sub-field of the Downstream Mapping TLV was adapted from text suggested by Curtis Villamizar. We would like to thank Loa Andersson for motivating the advancement - of this bis specification. + of this bis specification. We also would like to thank Alexander + Vainshtein for his review and comments. 8. References 8.1. Normative References [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - - Communication Layers", STD 3, RFC 1122, DOI 10.17487/ - RFC1122, October 1989, + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, . [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual - Private Network (VPN) Terminology", RFC 4026, DOI - 10.17487/RFC4026, March 2005, + Private Network (VPN) Terminology", RFC 4026, + DOI 10.17487/RFC4026, March 2005, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A - Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI - 10.17487/RFC4271, January 2006, + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, . [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, - February 2006. + DOI 10.17487/RFC4379, February 2006, + . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . 8.2. Informative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, - RFC 792, September 1981. + RFC 792, DOI 10.17487/RFC0792, September 1981, + . [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP - Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/ - RFC4365, February 2006, + Virtual Private Networks (VPNs)", RFC 4365, + DOI 10.17487/RFC4365, February 2006, . [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, + Label Distribution Protocol (LDP)", RFC 4447, + DOI 10.17487/RFC4447, April 2006, . [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . - [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit - Connectivity Verification (VCCV): A Control Channel for - Pseudowires", RFC 5085, December 2007. + [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, . Authors' Addresses Carlos Pignataro Cisco Systems, Inc. Email: cpignata@cisco.com + Nagendra Kumar Cisco Systems, Inc. Email: naikumar@cisco.com Sam Aldrin Google Email: aldrin.ietf@gmail.com