Network Working Group Tom Nadeau Internet Draft George Swallow Category: Standards Track David Ward Expiration Date: May 2007 Danny Prairie Cisco Systems, Inc. October 2006 Extensions to RFC4379 in Support of Link Bundles draft-nadeau-rfc4379-bis-link-bundle-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies extensions to MPLS LSP Ping's tracing function as specified in IETF RFC4379 to support link bundle constructs. In particular, we extend the Echo Request packet format to include a new Link Bundle TLV that can contain both the virtual link bundle interface ID, as well as a description of the ECMP algorithm used by said interface. The existing downstream mapping processing algorithm for midpoints is modified to specify that when link bundles are encountered, that the component links should be revealed as would non-component links in the existing algorithm. Nadeau, et al. Expires April 2007 [Page 1] Extensions to RFC4379 for link bundles October 15, 2006 Contents 1 Introduction .............................................. 3 1.1 Conventions ............................................... 3 1.2 Terminology ............................................... 3 2 Overview .................................................. 3 3 Connectivity Verification Bootstrapping ................... 4 3.1 Connectivity Verification Session Object .................. 4 6 Security Considerations ................................... 11 7 IANA Considerations ....................................... 11 8 Acknowledgments ........................................... 11 9 References ................................................ 11 9.1 Normative References ...................................... 11 9.2 Informative References .................................... 12 10 Authors' Addresses ........................................ 12 1. Introduction Link bundling is a technology that allows a device to group or "bundle" together multiple, dislike or like interfaces into a single link bundle interface. The constituent interfaces that are bundled together are referred to as component interfaces or links. The set of component links or interfaces all connect one router/switch to another. When associated under the umbrella of a single, virtual link bundle interface, they are still viewed in this way, but only as a single pipe to the adjacent neighbor, consisting of the combined bandwidth and other attributes of the component links. For example, a single set of transmit and receive counters reflect the aggregate behavior of the individual component links, and provide a single point of management for the operator. The algorithm used to share traffic across component links is often identical to the one used for spreading the load across adjacent IGP equal cost links, which is referred to as Equal Cost Multi-Path (ECMP). The most common algorithms are: 1) per-packet, which uses some form of round-robin scheduling to push each packet over a different component link or 2) per-destination, which sends all packets destined to a particular IP destination over the same component link. There are of course, pros and cons to using either algorithm, but the most common used is per-destination. Nadeau, et al. Expires April 2007 [Page 2] Extensions to RFC4379 for link bundles October 15, 2006 The motivation behind link bundling is to improve routing scalability by reducing the amount of information that has to be processed and advertised by the routing protocols such as OSPF or IS-IS. This reduction is accomplished by performing information aggregation/abstraction as described above. However, as well as the benefits to information aggregation, some negative side-effects result. Specifically, in cases where trouble-shooting or diagnosing failures related to malfunctioning link bundles, this information hiding compounds the time it takes a network manager to uncover the failure. For instance, if the failure has to do with one of the component links failing, depending on the hashing algorithm used to move traffic onto those component links, errors may appear random, or may be difficult to stimulate. This document specifies extensions to MPLS LSP Ping's tracing functions [RFC4379] to support link bundle constructs. To this end, we extend the Echo Request packet format to include a new options Link Bundle TLV (i.e.: U bit set to 1) will contain both the virtual link bundle interface ID, as well as a description of the ECMP algorithm used by link bundling interfaces on an MPLS Label Switching Router (LSR). The existing downstream mapping processing algorithm for midpoints is modified to specify that when link bundles are encountered, that the component links should be revealed as would non-component links in the existing algorithm. 1.1. Conventions 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 [KEYWORDS]. 1.2. Terminology Definitions of key terms for MPLS OAM are found in [RFC4379] and [RFC4201]. The reader is assumed to be familiar with those definitions which are not repeated here. The following additional terms are useful to understand this document. 1.3 Acronyms The following list of acronyms is a repeat of common acronyms defined in many other documents, and is provided here for convenience. Nadeau, et al. Expires April 2007 [Page 3] Extensions to RFC4379 for link bundles October 15, 2006 CE: Customer Edge PE: Provider Edge ECMP: Equal Cost Multipath LDP: Label Distribution Protocol LSP: Label Switch Path LSR: Label Switch Router OAM: Operations and Management OA&M: Operations, Administration and Maintenance. RSVP: Resource reSerVation Protocol SP: Service Provider 2. Overview In section 3, we extend the Echo Request packet format to include a new (optional) Link Bundle TLV that will contain both the virtual link bundle interface ID, as well as a description of the ECMP algorithm used by said interface. The the existing downstream mapping processing algorithm for midpoints is modified to specify that when link bundles are encountered, that the component links should be revealed as would non-component links in the existing algorithm. The error processing algorithm will also be modified to indicate that a component of a virtual link bundle interface has failed. The presence of the Link Bundle TLV will indicate that a link bundle virtual interface is associated with those component links, and that special processing and consideration at the head-end LSR of the LSP should be taken when processing this information. The head-end LSR's processing algorithm is modified to understand the new aforementioned Link Bundle TLV, as well as to modify its processing algorithm for how it investigiates the LSP's tree when tracing either the entire tree using ECMP tree trace, or tracing a single path (also known as a path selector) of the LSP. This is all detailed below. 4. Downstream Mapping Processing For Link Bundles Use the algorithm as stated in RFC4379 with the following modifications: [At the receiver of an Echo Request containing a Downstream Map TLV] 1) When encoding the downstream map tlv, and encountering a link bundle virtual interface, recurse through to each one of its component link interfaces and include those (their IP address and IfNumber) in Nadeau, et al. Expires April 2007 [Page 4] Extensions to RFC4379 for link bundles October 15, 2006 the Downstream Map TLV. For each one included, also set the DS Flag to indicate that it is a component link interface. The multipath type specified is used to fully resolve the outgoing path to a particular component link of the bundle. In other words, multipath type A is not used to perform resolution to a bundle, and then multipath type B used to further resolve to a component link. That is, run the ECMP algorithm twice, once using the virtual link bundle interface as the next-hop, and then again through that interface to the component link bundle interfaces. In most cases, the ECMP algorithm used for the link bundles will be identical to the one used to get from the link bundle interface to the component interfaces, and thus can simply be run twice by the control plane. 2) Include one copy of the Downstream Map Link Bundle TLV for each link bundle virtual interface. For each TLV, fill in the component links herein to "point" back at the link bundle component links specified in #1. [At the receiver of an Echo Reply containing a Downstream Map TLV] 1) Ensure that for each Downstream Map TLV containing an interface with the DS Flag of "L" set, verify that a Downstream Map Link Bundle TLV exists that contains this interface, or return an error. Older versions of code will ignore this flag. 2) For each component interface present in the Downstream Mapping TLV, process as normal. This facilitates backwards compatibility with older code. 3) For each Downstream Map Link Bundle TLV, iterate through the component interfaces specified therein, and ensure they match the ones specified in the Downstream Map TLV discussed in 1. 3.3. Downstream Mapping When Supporting Link Bundles The description of interfaces in Section 3.3 "Downstream Mapping" of [RFC4379] must be changed to reflect each set of link bundle component interfaces belonging to a link bundle as follows. The entire section has been copied here and modified in place for completeness. Nadeau, et al. Expires April 2007 [Page 5] Extensions to RFC4379 for link bundles October 15, 2006 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. For a more precise definition of the notion of "downstream", see section 3.3.2, "Downstream Router and Interface". The Length is K + M + 4*N octets, where M is the Multipath Length, and N is the number of Downstream Labels. Values for K are found in the description of Address Type below. The Value field of a Downstream Mapping has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | DS Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IP Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Interface Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multipath Type| Depth Limit | Multipath Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (Multipath Information) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Transmission Unit (MTU) The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the interface to the Downstream LSR. Address Type The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the Downstream IP Nadeau, et al. Expires April 2007 [Page 6] Extensions to RFC4379 for link bundles October 15, 2006 Address and Downstream Interface fields. The resulting total for the initial part of the TLV is listed in the table below as "K Octets". In the case where the interface is a virtual link bundle interface, the LSR MUST include its component interfaces addresses here and MUST NOT include the virtual link bundle. It must also indicate that it is a component link by setting the L bit in the DS Flags. Under this condition, the LSR MUST then include a corresponding Link Bundle TLV (see below) to indicate which component interfaces are associated with which component links returned in the DS Map TLV. Type # Address Type K Octets ------ ------------ -------- 1 IPv4 Numbered 16 2 IPv4 Unnumbered 16 3 IPv6 Numbered 40 4 IPv6 Unnumbered 28 DS Flags The DS Flags field is a bit vector with the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Rsvd(MBZ)|L|I|N| +-+-+-+-+-+-+-+-+ Three flags are defined currently, I, N and L. The remaining flags MUST be set to zero when sending and ignored on receipt. Flag Name and Meaning ---- ---------------- I Interface and Label Stack Object Request When this flag is set, it indicates that the replying router SHOULD include an Interface and Label Stack Object in the echo reply message. N Treat as a Non-IP Packet Echo request messages will be used to diagnose non-IP flows. However, these messages are carried in IP packets. For a router that alters its ECMP algorithm based on the FEC or deep packet examination, this flag Nadeau, et al. Expires April 2007 [Page 7] Extensions to RFC4379 for link bundles October 15, 2006 requests that the router treat this as it would if the determination of an IP payload had failed. L Link Bundle Component Interface When this flag is set, it indicates that the interface indicated in the Downstream Interface Address field is a member of a link bundle (i.e.: a component link bundle interface). Downstream IP Address and Downstream Interface Address IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets. If the interface to the downstream LSR is numbered, then the Address Type MUST be set to IPv4 or IPv6, the Downstream IP Address MUST be set to either the downstream LSR's Router ID or the interface address of the downstream LSR, and the Downstream Interface Address MUST be set to the downstream LSR's interface address. If the interface to the downstream LSR is unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP Address MUST be the downstream LSR's Router ID, and the Downstream Interface Address MUST be set to the index assigned by the upstream LSR to the interface. If an LSR does not know the IP address of its neighbor, then it MUST set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it must set the Downstream IP Address to 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with either of these addresses in the Downstream IP Address field, this indicates that it MUST bypass interface verification but continue with label validation. If the originator of an Echo Request packet wishes to obtain Downstream Mapping information but does not know the expected label stack, then it SHOULD set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the Downstream IP Address to 224.0.0.2; for IPv6 the address MUST be set to FF02::2. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with the all-routers multicast address, then this indicates that it MUST bypass both interface and label stack validation, but return Downstream Mapping TLVs using the information provided. Multipath Type Nadeau, et al. Expires April 2007 [Page 8] Extensions to RFC4379 for link bundles October 15, 2006 The following Multipath Types are defined: Key Type Multipath Information --- ---------------- --------------------- 0 no multipath Empty (Multipath Length = 0) 2 IP address IP addresses 4 IP address range low/high address pairs 8 Bit-masked IP IP address prefix and bit mask address set 9 Bit-masked label set Label prefix and bit mask Type 0 indicates that all packets will be forwarded out this one interface. Types 2, 4, 8, and 9 specify that the supplied Multipath Information will serve to exercise this path. Depth Limit The Depth Limit is applicable only to a label stack and is the maximum number of labels considered in the hash; this SHOULD be set to zero if unspecified or unlimited. Multipath Length The length in octets of the Multipath Information. Multipath Information Address or label values encoded according to the Multipath Type. In the case where the L bit is set in the DS Flags, the multipath information MUST also be set to reflect the multipath address or label value encoding that link bundle interface will use to load share traffic onto this component interface. The parameters used to get traffic from the inbound interface to the link bundle virtual interface will be described in the Multipath Information for Link Bundles section below. See the next section below for encoding details. Downstream Label(s) The set of labels in the label stack as it would have appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are explicitly included. Labels are treated as numbers, i.e., they are right justified in the field. Nadeau, et al. Expires April 2007 [Page 9] Extensions to RFC4379 for link bundles October 15, 2006 A Downstream Label is 24 bits, in the same format as an MPLS label minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The replying router SHOULD fill in the EXP and S bits; the LSR receiving the echo reply MAY choose to ignore these bits. Protocol The Protocol is taken from the following table: Protocol # Signaling Protocol ---------- ------------------ 0 Unknown 1 Static 2 BGP 3 LDP 4 RSVP-TE 5 Link Bundle Component Interface In the case where a link bundle's component interface is specified (as indicated by DS Flag L), the value of 5 (Link Bundle Component Interface MUST be used as the protocol identifier. 10. Downstream Mapping Link Bundle TLV The Downstream Mapping Link Bundle object is a TLV that SHOULD NOT be included in an echo request message. This TLV is used to specify the link bundle virtual interface, as well as which link bundle virtual interface corresponds to which link bundle component interfaces that were specified in the Downstream Mapping TLV. If the replying router is the destination of the FEC, then a Downstream Mapping Link Bundle TLV SHOULD NOT be included in the Echo Reply. Otherwise the replying router MUST include a Downstream Mapping Link Bundle object for each link bundle virtual interface over which this FEC could be forwarded. Furthermore, this TLV will be present once for every Downstream Mapping TLV present that contains a DS Flag set to L. For a more precise definition of the notion of "downstream", see section 3.3.2, "Downstream Router and Interface". The Length is K + M + 4*N octets, where M is the Multipath Length, and N is the number of Downstream Labels. Values for K are found in the description of Address Type below. The Value field of a Downstream Mapping has the following format: 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 Nadeau, et al. Expires April 2007 [Page 10] Extensions to RFC4379 for link bundles October 15, 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Address Type | DS Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream IP Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Interface Address (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multipath Type| Reserved | Multipath Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (Multipath Information) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Interface Address | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Interface's Downstream Map TLV index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Interface Address | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Interface's Downstream Map TLV index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Transmission Unit (MTU) The MTU is the size in octets of the largest MPLS frame (including label stack) that fits on the virtual interface to the Downstream LSR. Address Type The Address Type indicates if the virtual interface is numbered or unnumbered. It also determines the length of the Downstream IP Address and Downstream Interface fields. The resulting total for the initial part of the TLV is listed in the table below as "K Octets". The Address Type is set to one of the following values: Type # Address Type K Octets ------ ------------ -------- 1 IPv4 Numbered 16 2 IPv4 Unnumbered 16 3 IPv6 Numbered 40 4 IPv6 Unnumbered 28 DS Link Bundle Flags Nadeau, et al. Expires April 2007 [Page 11] Extensions to RFC4379 for link bundles October 15, 2006 The DS Flags field is a bit vector with the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Rsvd(MBZ) | +-+-+-+-+-+-+-+-+ All flags are reserved for future use and MUST be set to zero when sending and ignored on receipt. Downstream IP Address and Downstream Component Interface Address IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets. If the link bundle component interface to the downstream LSR is numbered, then the Address Type MUST be set to IPv4 or IPv6, the Downstream IP Address MUST be set to either the downstream LSR's Router ID or the interface address of the downstream LSR, and the Downstream Interface Address MUST be set to the downstream LSR's interface address. The interface index is set to the value assigned by the LSR. If the link bundle interface to the downstream LSR is unnumbered, the Address Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP Address MUST be the downstream LSR's Router ID, and the Downstream Interface Address MUST be set to the interface index assigned by the upstream LSR to the interface. If an LSR does not know the IP address of its neighbor, then it MUST set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it must set the Downstream IP Address to 127.0.0.1; for IPv6 the address is set to 0::1. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with either of these addresses in the Downstream IP Address field, this indicates that it MUST bypass interface verification but continue with label validation. If the originator of an Echo Request packet wishes to obtain Downstream Mapping Link Bundle information but does not know the expected label stack, then it SHOULD set the Address Type to either IPv4 Unnumbered or IPv6 Unnumbered. For IPv4, it MUST set the Downstream IP Address to 224.0.0.2; for IPv6 the address MUST be set to FF02::2. In both cases, the interface index MUST be set to 0. If an LSR receives an Echo Request packet with the all-routers multicast address, then this indicates that it MUST bypass both interface and label stack validation, but return Downstream Mapping TLVs using the information provided. Nadeau, et al. Expires April 2007 [Page 12] Extensions to RFC4379 for link bundles October 15, 2006 Multipath Type This field specifies an additional multipath type if it differs from the one specified for the link bundle component interfaces specified in the Downstream Map TLV. Definition is the same as those from RFC4379. Depth Limit The Depth Limit is applicable only to a label stack and is the maximum number of labels considered in the hash; this SHOULD be set to zero if unspecified or unlimited. Multipath Length The length in octets of the Multipath Information. Multipath Information Address or label values encoded according to the Multipath Type. See the next section below for encoding details. Downstream Label(s) The set of labels in the label stack as it would have appeared if this router were forwarding the packet through this interface. Any Implicit Null labels are explicitly included. Labels are treated as numbers, i.e., they are right justified in the field. A Downstream Label is 24 bits, in the same format as an MPLS label minus the TTL field, i.e., the MSBit of the label is bit 0, the LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S bit. The replying router SHOULD fill in the EXP and S bits; the LSR receiving the echo reply MAY choose to ignore these bits. Protocol The Protocol is taken from the following table: Protocol # Signaling Protocol ---------- ------------------ 0 Unknown 1 Static 2 BGP 3 LDP 4 RSVP-TE Nadeau, et al. Expires April 2007 [Page 13] Extensions to RFC4379 for link bundles October 15, 2006 3.3.2. Downstream Router and Interface Section 3 of RFC3479 contains a description of TLV types. The Downstream Mapping Link Bundle TLV will be assigned a Type value of 11 as follows. A description of the Types and Values of the top-level TLVs for LSP ping are given below: Type # Value Field ------ ----------- 1 Target FEC Stack 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 10 Reply TOS Byte 11 Downstream Mapping Link Bundle 6. Security Considerations TBD 7. IANA Considerations This document makes the following code point assignments (pending IANA action): Registry Code point Purpose UDP Port tba MPLS Verification Request LSP Ping Message Type 5 MPLS Connectivity Verification Probe LSP Ping Object Type 13 Connectivity Verification Parameters LSP Ping FEC Stack tba Multicast LDP FEC Sub-object Type Nadeau, et al. Expires April 2007 [Page 14] Extensions to RFC4379 for link bundles October 15, 2006 8. Acknowledgments The authors would like to thank Vanson Lim for his comments and suggestions. 9. References 9.1. Normative References [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [SELF-TST] Swallow, G. et al., "Label Switching Router Self-Test", , June 2006. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MCSTPING] "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", , April 2006. 9.2. Informative References [MPLS-BFD] Aggarwal, R., et al., " 10. Authors' Addresses George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 USA Email: swallow@cisco.com Tom Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 USA Nadeau, et al. Expires April 2007 [Page 15] Extensions to RFC4379 for link bundles October 15, 2006 Email: tnadeau@cisco.com Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: dward@cisco.com Danny Prairie Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 CANADA Phone: +1.613.274.3544 Email: dprairie@cisco.com Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Nadeau, et al. Expires April 2007 [Page 16] Extensions to RFC4379 for link bundles October 15, 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Nadeau, et al. Expires April 2007 [Page 17]