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",
<draft-ietf-mpls-lsr-self-test-07.txt>, 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",
<draft-ietf-mpls-p2mp-lsp-ping-01.txt>, 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]