draft-smack-mpls-rfc4379bis-01.txt   draft-smack-mpls-rfc4379bis-02.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Network Working Group C. Pignataro Network Working Group C. Pignataro
Internet-Draft N. Kumar Internet-Draft N. Kumar
Obsoletes: 4379 (if approved) Cisco Obsoletes: 4379 (if approved) Cisco
Intended status: Standards Track S. Aldrin Intended status: Standards Track S. Aldrin
Expires: March 29, 2016 Google Expires: March 29, 2016 Google
M. Chen M. Chen
Huawei Huawei
September 26, 2015 September 26, 2015
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
draft-smack-mpls-rfc4379bis-01.txt draft-smack-mpls-rfc4379bis-02
Abstract Abstract
This document describes a simple and efficient mechanism that can be This document describes a simple and efficient mechanism that can be
used to detect data plane failures in Multi-Protocol Label Switching used to detect data plane failures in Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs). There are two parts to this (MPLS) Label Switched Paths (LSPs). There are two parts to this
document: information carried in an MPLS "echo request" and "echo document: information carried in an MPLS "echo request" and "echo
reply" for the purposes of fault detection and isolation, and reply" for the purposes of fault detection and isolation, and
mechanisms for reliably sending the echo reply. mechanisms for reliably sending the echo reply.
skipping to change at page 2, line 48 skipping to change at page 2, line 48
3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . 21 3.2.14. Generic IPv6 Prefix . . . . . . . . . . . . . . . . 21
3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . 22 3.2.15. Nil FEC . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 22 3.3. Downstream Mapping . . . . . . . . . . . . . . . . . . . 22
3.3.1. Multipath Information Encoding . . . . . . . . . . . 26 3.3.1. Multipath Information Encoding . . . . . . . . . . . 26
3.3.2. Downstream Router and Interface . . . . . . . . . . 28 3.3.2. Downstream Router and Interface . . . . . . . . . . 28
3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. Pad TLV . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 29 3.5. Vendor Enterprise Number . . . . . . . . . . . . . . . . 29
3.6. Interface and Label Stack . . . . . . . . . . . . . . . 29 3.6. Interface and Label Stack . . . . . . . . . . . . . . . 29
3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 31 3.7. Errored TLVs . . . . . . . . . . . . . . . . . . . . . . 31
3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 31 3.8. Reply TOS Byte TLV . . . . . . . . . . . . . . . . . . . 31
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . 32 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . 31
4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . 32 4.1. Dealing with Equal-Cost Multi-Path (ECMP) . . . . . . . 32
4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . 33 4.2. Testing LSPs That Are Used to Carry MPLS Payloads . . . 33
4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 33 4.3. Sending an MPLS Echo Request . . . . . . . . . . . . . . 33
4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 34 4.4. Receiving an MPLS Echo Request . . . . . . . . . . . . . 34
4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 40 4.4.1. FEC Validation . . . . . . . . . . . . . . . . . . . 40
4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 41 4.5. Sending an MPLS Echo Reply . . . . . . . . . . . . . . . 41
4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 42 4.6. Receiving an MPLS Echo Reply . . . . . . . . . . . . . . 42
4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . 42 4.7. Issue with VPN IPv4 and IPv6 Prefixes . . . . . . . . . 42
4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . 43 4.8. Non-compliant Routers . . . . . . . . . . . . . . . . . 42
5. Security Considerations . . . . . . . . . . . . . . . . . . 43 5. Security Considerations . . . . . . . . . . . . . . . . . . 43
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44
6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 45 6.1. Message Types, Reply Modes, Return Codes . . . . . . . . 44
6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.1. Normative References . . . . . . . . . . . . . . . . . . 47 8.1. Normative References . . . . . . . . . . . . . . . . . . 47
8.2. Informative References . . . . . . . . . . . . . . . . . 48 8.2. Informative References . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document describes a simple and efficient mechanism that can be This document describes a simple and efficient mechanism that can be
skipping to change at page 5, line 5 skipping to change at page 5, line 5
1.4. Scope of RFC4379bis work 1.4. Scope of RFC4379bis work
The goal of this document is to take LSP Ping to an Internet The goal of this document is to take LSP Ping to an Internet
Standard. Standard.
[RFC4379] defines the basic mechanism for MPLS LSP validation that [RFC4379] defines the basic mechanism for MPLS LSP validation that
can be used for fault detection and isolation. The scope of this can be used for fault detection and isolation. The scope of this
document also is to address various updates to MPLS LSP Ping, document also is to address various updates to MPLS LSP Ping,
including: including:
1. Updates to all references and citations. 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 Errata with
IDs: 108, 1418, 1714, 1786, 3399, 742, and 2978.
1.5. ToDo 1.5. ToDo
Please remove this ToDo prior to publication: Please remove this ToDo prior to publication:
1. Incorporate Errata 1. Review IANA Allocations
2. Review IANA Allocations 2. Fix pending figure mis-alignments
2. Motivation 2. Motivation
When an LSP fails to deliver user traffic, the failure cannot always 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 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 tool that would enable users to detect such traffic "black holes" or
misrouting within a reasonable period of time, and a mechanism to misrouting within a reasonable period of time, and a mechanism to
isolate faults. isolate faults.
In this document, we describe a mechanism that accomplishes these In this document, we describe a mechanism that accomplishes these
skipping to change at page 8, line 5 skipping to change at page 8, line 5
The 127/8 address range provides 16M addresses allowing wide The 127/8 address range provides 16M addresses allowing wide
flexibility in varying addresses to exercise ECMP paths. Finally, as flexibility in varying addresses to exercise ECMP paths. Finally, as
an implementation optimization, the 127/8 provides an easy means of an implementation optimization, the 127/8 provides an easy means of
identifying possible LSP packets. identifying possible LSP packets.
3. Packet Format 3. Packet Format
An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet; An MPLS echo request is a (possibly labeled) IPv4 or IPv6 UDP packet;
the contents of the UDP packet have the following format: the contents of the UDP packet have the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags | | Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode| | Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle | | Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) | | TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) | | TimeStamp Sent (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) | | TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) | | TimeStamp Received (seconds fraction) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... | | TLVs ... |
. . . .
. . . .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Version Number is currently 1. (Note: the version number is to The Version Number is currently 1. (Note: the version number is to
be incremented whenever a change is made that affects the ability of be incremented whenever a change is made that affects the ability of
an implementation to correctly parse or process an MPLS echo an implementation to correctly parse or process an MPLS echo
request/reply. These changes include any syntactic or semantic request/reply. These changes include any syntactic or semantic
changes made to any of the fixed fields, or to any Type-Length-Value changes made to any of the fixed fields, or to any Type-Length-Value
(TLV) or sub-TLV assignment or format that is defined at a certain (TLV) or sub-TLV assignment or format that is defined at a certain
version number. The version number may not need to be changed if an version number. The version number may not need to be changed if an
optional TLV or sub-TLV is added.) optional TLV or sub-TLV is added.)
The Global Flags field is a bit vector with the following format: The Global Flags field is a bit vector with the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V| | MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag is defined for now, the V bit; the rest MUST be set to zero One flag is defined for now, the V bit; the rest MUST be set to zero
when sending and ignored on receipt. when sending and ignored on receipt.
The V (Validate FEC Stack) flag is set to 1 if the sender wants the The V (Validate FEC Stack) flag is set to 1 if the sender wants the
receiver to perform FEC Stack validation; if V is 0, the choice is receiver to perform FEC Stack validation; if V is 0, the choice is
skipping to change at page 10, line 8 skipping to change at page 10, line 8
Return Codes and Subcodes are described in the next section. Return Codes and Subcodes are described in the next section.
The Sender's Handle is filled in by the sender, and returned The Sender's Handle is filled in by the sender, and returned
unchanged by the receiver in the echo reply (if any). There are no unchanged by the receiver in the echo reply (if any). There are no
semantics associated with this handle, although a sender may find semantics associated with this handle, although a sender may find
this useful for matching up requests with replies. this useful for matching up requests with replies.
The Sequence Number is assigned by the sender of the MPLS echo The Sequence Number is assigned by the sender of the MPLS echo
request and can be (for example) used to detect missed replies. request and can be (for example) used to detect missed replies.
The TimeStamp Sent is the time-of-day (in seconds and microseconds, The TimeStamp Sent is the time-of-day (according to the sender's
according to the sender's clock) in NTP format [RFC5905] when the clock) in NTP format [RFC5905] when the MPLS echo request is sent.
MPLS echo request is sent. The TimeStamp Received in an echo reply The TimeStamp Received in an echo reply is the time-of-day (according
is the time-of-day (according to the receiver's clock) in NTP format to the receiver's clock) in NTP format that the corresponding echo
that the corresponding echo request was received. request was received.
TLVs (Type-Length-Value tuples) have the following format: TLVs (Type-Length-Value tuples) have the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
skipping to change at page 10, line 37 skipping to change at page 10, line 37
Types are defined below; Length is the length of the Value field in Types are defined below; Length is the length of the Value field in
octets. The Value field depends on the Type; it is zero padded to octets. The Value field depends on the Type; it is zero padded to
align to a 4-octet boundary. TLVs may be nested within other TLVs, align to a 4-octet boundary. TLVs may be nested within other TLVs,
in which case the nested TLVs are called sub-TLVs. Sub-TLVs have in which case the nested TLVs are called sub-TLVs. Sub-TLVs have
independent types and MUST also be 4-octet aligned. independent types and MUST also be 4-octet aligned.
Two examples follow. The Label Distribution Protocol (LDP) IPv4 FEC Two examples follow. The Label Distribution Protocol (LDP) IPv4 FEC
sub-TLV has the following format: sub-TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (LDP IPv4 FEC) | Length = 5 | | Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this TLV is 5. A Target FEC Stack TLV that contains The Length for this TLV is 5. A Target FEC Stack TLV that contains
an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the an LDP IPv4 FEC sub-TLV and a VPN IPv4 prefix sub-TLV has the
following format: following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (FEC TLV) | Length = 12 | | Type = 1 (FEC TLV) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 | | sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 prefix)| Length = 13 | | sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
skipping to change at page 14, line 17 skipping to change at page 14, line 17
3.2.1. LDP IPv4 Prefix 3.2.1. LDP IPv4 Prefix
The IPv4 Prefix FEC is defined in [RFC5036]. When an LDP IPv4 prefix The IPv4 Prefix FEC is defined in [RFC5036]. When an LDP IPv4 prefix
is encoded in a label stack, the following format is used. The value is encoded in a label stack, the following format is used. The value
consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix consists of 4 octets of an IPv4 prefix followed by 1 octet of prefix
length in bits; the format is given below. The IPv4 prefix is in length in bits; the format is given below. The IPv4 prefix is in
network byte order; if the prefix is shorter than 32 bits, trailing network byte order; if the prefix is shorter than 32 bits, trailing
bits SHOULD be set to zero. See [RFC5036] for an example of a bits SHOULD be set to zero. See [RFC5036] for an example of a
Mapping for an IPv4 FEC. Mapping for an IPv4 FEC.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. LDP IPv6 Prefix 3.2.2. LDP IPv6 Prefix
The IPv6 Prefix FEC is defined in [RFC5036]. When an LDP IPv6 prefix The IPv6 Prefix FEC is defined in [RFC5036]. When an LDP IPv6 prefix
is encoded in a label stack, the following format is used. The value is encoded in a label stack, the following format is used. The value
consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix consists of 16 octets of an IPv6 prefix followed by 1 octet of prefix
length in bits; the format is given below. The IPv6 prefix is in length in bits; the format is given below. The IPv6 prefix is in
network byte order; if the prefix is shorter than 128 bits, the network byte order; if the prefix is shorter than 128 bits, the
trailing bits SHOULD be set to zero. See [RFC5036] for an example of trailing bits SHOULD be set to zero. See [RFC5036] for an example of
a Mapping for an IPv6 FEC. a Mapping for an IPv6 FEC.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| (16 octets) | | (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. RSVP IPv4 LSP 3.2.3. RSVP IPv4 LSP
The value has the format below. The value fields are taken from RFC The value has the format below. The value fields are taken from RFC
3209, sections 4.6.1.1 and 4.6.2.1. See [RFC3209]. 3209, sections 4.6.1.1 and 4.6.2.1. See [RFC3209].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.4. RSVP IPv6 LSP 3.2.4. RSVP IPv6 LSP
The value has the format below. The value fields are taken from RFC The value has the format below. The value fields are taken from RFC
3209, sections 4.6.1.2 and 4.6.2.2. See [RFC3209]. 3209, sections 4.6.1.2 and 4.6.2.2. See [RFC3209].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address | | IPv6 tunnel end point address |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
skipping to change at page 16, line 10 skipping to change at page 16, line 10
VPN-IPv4 Network Layer Routing Information (NLRI) is defined in VPN-IPv4 Network Layer Routing Information (NLRI) is defined in
[RFC4365]. This document uses the term VPN IPv4 prefix for a VPN- [RFC4365]. This document uses the term VPN IPv4 prefix for a VPN-
IPv4 NLRI that has been advertised with an MPLS label in BGP. See IPv4 NLRI that has been advertised with an MPLS label in BGP. See
[RFC3107]. [RFC3107].
When a VPN IPv4 prefix is encoded in a label stack, the following When a VPN IPv4 prefix is encoded in a label stack, the following
format is used. The value field consists of the Route Distinguisher format is used. The value field consists of the Route Distinguisher
advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0 advertised with the VPN IPv4 prefix, the IPv4 prefix (with trailing 0
bits to make 32 bits in all), and a prefix length, as follows: bits to make 32 bits in all), and a prefix length, as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 39 skipping to change at page 16, line 39
VPN-IPv6 Network Layer Routing Information (NLRI) is defined in VPN-IPv6 Network Layer Routing Information (NLRI) is defined in
[RFC4365]. This document uses the term VPN IPv6 prefix for a VPN- [RFC4365]. This document uses the term VPN IPv6 prefix for a VPN-
IPv6 NLRI that has been advertised with an MPLS label in BGP. See IPv6 NLRI that has been advertised with an MPLS label in BGP. See
[RFC3107]. [RFC3107].
When a VPN IPv6 prefix is encoded in a label stack, the following When a VPN IPv6 prefix is encoded in a label stack, the following
format is used. The value field consists of the Route Distinguisher format is used. The value field consists of the Route Distinguisher
advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0 advertised with the VPN IPv6 prefix, the IPv6 prefix (with trailing 0
bits to make 128 bits in all), and a prefix length, as follows: bits to make 128 bits in all), and a prefix length, as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 30 skipping to change at page 17, line 30
when matching these fields to local FEC information, they are treated when matching these fields to local FEC information, they are treated
as opaque values. The encapsulation type is identical to the PW Type as opaque values. The encapsulation type is identical to the PW Type
in section 3.2.8 below. in section 3.2.8 below.
When an L2 VPN endpoint is encoded in a label stack, the following When an L2 VPN endpoint is encoded in a label stack, the following
format is used. The value field consists of a Route Distinguisher (8 format is used. The value field consists of a Route Distinguisher (8
octets), the sender (of the ping)'s VE ID (2 octets), the receiver's octets), the sender (of the ping)'s VE ID (2 octets), the receiver's
VE ID (2 octets), and an encapsulation type (2 octets), formatted as VE ID (2 octets), and an encapsulation type (2 octets), formatted as
follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | | Route Distinguisher |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID | | Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero | | Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 7 skipping to change at page 18, line 7
32-bit connection ID. The PW Type is a 15-bit number indicating the 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 encapsulation type. It is carried right justified in the field below
termed encapsulation type with the high-order bit set to zero. Both termed encapsulation type with the high-order bit set to zero. Both
of these fields are treated in this protocol as opaque values. 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 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 address (the
destination address of the targeted LDP session), the PW ID, and the destination address of the targeted LDP session), the PW ID, and the
encapsulation type as follows: encapsulation type as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID | | PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero | | PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This FEC is deprecated and is retained only for backward This FEC is deprecated and is retained only for backward
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Both of these fields are treated in this protocol as opaque values. Both of these fields are treated in this protocol as opaque values.
When matching these field to the local FEC information, the match When matching these field to the local FEC information, the match
MUST be exact. MUST be exact.
When an FEC 128 is encoded in a label stack, the following format is 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 used. The value field consists of the sender's PE address (the
source address of the targeted LDP session), the remote PE address source address of the targeted LDP session), the remote PE address
(the destination address of the targeted LDP session), the PW ID, and (the destination address of the targeted LDP session), the PW ID, and
the encapsulation type as follows: the encapsulation type as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID | | PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero | | PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 5 skipping to change at page 20, line 5
fields are treated as opaque values and copied directly from the FEC fields are treated as opaque values and copied directly from the FEC
129 format. All of these values together uniquely define 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 within the scope of the LDP session identified by the source and
remote PE addresses. remote PE addresses.
When an FEC 129 is encoded in a label stack, the following format is 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 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; 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. the length of the padding is not included in the Length field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address | | Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length | | PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~ ~ AGI Value ~
| | | |
skipping to change at page 20, line 36 skipping to change at page 20, line 36
| TAII (cont.) | 0-3 octets of zero padding | | TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. BGP Labeled IPv4 Prefix 3.2.11. BGP Labeled IPv4 Prefix
BGP labeled IPv4 prefixes are defined in [RFC3107]. When a BGP BGP labeled IPv4 prefixes are defined in [RFC3107]. When a BGP
labeled IPv4 prefix is encoded in a label stack, the following format labeled IPv4 prefix is encoded in a label stack, the following format
is used. The value field consists the IPv4 prefix (with trailing 0 is used. The value field consists the IPv4 prefix (with trailing 0
bits to make 32 bits in all), and the prefix length, as follows: bits to make 32 bits in all), and the prefix length, as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix | | IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.12. BGP Labeled IPv6 Prefix 3.2.12. BGP Labeled IPv6 Prefix
BGP labeled IPv6 prefixes are defined in [RFC3107]. When a BGP BGP labeled IPv6 prefixes are defined in [RFC3107]. When a BGP
labeled IPv6 prefix is encoded in a label stack, the following format labeled IPv6 prefix is encoded in a label stack, the following format
is used. The value consists of 16 octets of an IPv6 prefix followed is used. The value consists of 16 octets of an IPv6 prefix followed
by 1 octet of prefix length in bits; the format is given below. The by 1 octet of prefix length in bits; the format is given below. The
IPv6 prefix is in network byte order; if the prefix is shorter than IPv6 prefix is in network byte order; if the prefix is shorter than
128 bits, the trailing bits SHOULD be set to zero. 128 bits, the trailing bits SHOULD be set to zero.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| (16 octets) | | (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 28 skipping to change at page 21, line 28
The value consists of 4 octets of an IPv4 prefix followed by 1 octet The value consists of 4 octets of an IPv4 prefix followed by 1 octet
of prefix length in bits; the format is given below. The IPv4 prefix of prefix length in bits; the format is given below. The IPv4 prefix
is in network byte order; if the prefix is shorter than 32 bits, is in network byte order; if the prefix is shorter than 32 bits,
trailing bits SHOULD be set to zero. This FEC is used if the trailing bits SHOULD be set to zero. This FEC is used if the
protocol advertising the label is unknown or may change during the protocol advertising the label is unknown or may change during the
course of the LSP. An example is an inter-AS LSP that may be course of the LSP. An example is an inter-AS LSP that may be
signaled by LDP in one Autonomous System (AS), by RSVP-TE [RFC3209] signaled by LDP in one Autonomous System (AS), by RSVP-TE [RFC3209]
in another AS, and by BGP between the ASes, such as is common for in another AS, and by BGP between the ASes, such as is common for
inter-AS VPNs. inter-AS VPNs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix | | IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.14. Generic IPv6 Prefix 3.2.14. Generic IPv6 Prefix
The value consists of 16 octets of an IPv6 prefix followed by 1 octet The value consists of 16 octets of an IPv6 prefix followed by 1 octet
of prefix length in bits; the format is given below. The IPv6 prefix of prefix length in bits; the format is given below. The IPv6 prefix
is in network byte order; if the prefix is shorter than 128 bits, the is in network byte order; if the prefix is shorter than 128 bits, the
trailing bits SHOULD be set to zero. trailing bits SHOULD be set to zero.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix | | IPv6 prefix |
| (16 octets) | | (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero | | Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 17 skipping to change at page 22, line 17
At times, labels from the reserved range, e.g., Router Alert and At times, labels from the reserved range, e.g., Router Alert and
Explicit-null, may be added to the label stack for various diagnostic Explicit-null, may be added to the label stack for various diagnostic
purposes such as influencing load-balancing. These labels may have purposes such as influencing load-balancing. These labels may have
no explicit FEC associated with them. The Nil FEC Stack is defined no explicit FEC associated with them. The Nil FEC Stack is defined
to allow a Target FEC Stack sub-TLV to be added to the Target FEC to allow a Target FEC Stack sub-TLV to be added to the Target FEC
Stack to account for such labels so that proper validation can still Stack to account for such labels so that proper validation can still
be performed. be performed.
The Length is 4. Labels are 20-bit values treated as numbers. The Length is 4. Labels are 20-bit values treated as numbers.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label is the actual label value inserted in the label stack; the MBZ Label is the actual label value inserted in the label stack; the MBZ
fields MUST be zero when sent and ignored on receipt. fields MUST be zero when sent and ignored on receipt.
3.3. Downstream Mapping 3.3. Downstream Mapping
skipping to change at page 23, line 5 skipping to change at page 23, line 5
Otherwise the replying router SHOULD include a Downstream Mapping Otherwise the replying router SHOULD include a Downstream Mapping
object for each interface over which this FEC could be forwarded. object for each interface over which this FEC could be forwarded.
For a more precise definition of the notion of "downstream", see For a more precise definition of the notion of "downstream", see
section 3.3.2, "Downstream Router and Interface". section 3.3.2, "Downstream Router and Interface".
The Length is K + M + 4*N octets, where M is the Multipath Length, 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 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 the description of Address Type below. The Value field of a
Downstream Mapping has the following format: Downstream Mapping has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | | MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) | | Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) | | Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length | | Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 35 skipping to change at page 26, line 35
2 BGP 2 BGP
3 LDP 3 LDP
4 RSVP-TE 4 RSVP-TE
3.3.1. Multipath Information Encoding 3.3.1. Multipath Information Encoding
The Multipath Information encodes labels or addresses that will The Multipath Information encodes labels or addresses that will
exercise this path. The Multipath Information depends on the exercise this path. The Multipath Information depends on the
Multipath Type. The contents of the field are shown in the table Multipath Type. The contents of the field are shown in the table
above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses
are drawn from the range 0:0:0:0:0:FFFF:127/104. Labels are treated are drawn from the range 0:0:0:0:0:FFFF:7F00/104. Labels are treated
as numbers, i.e., they are right justified in the field. For Type 4, as numbers, i.e., they are right justified in the field. For Type 4,
ranges indicated by Address pairs MUST NOT overlap and MUST be in ranges indicated by Address pairs MUST NOT overlap and MUST be in
ascending sequence. ascending sequence.
Type 8 allows a more dense encoding of IP addresses. The IP prefix Type 8 allows a more dense encoding of IP addresses. The IP prefix
is formatted as a base IP address with the non-prefix low-order bits is formatted as a base IP address with the non-prefix low-order bits
set to zero. The maximum prefix length is 27. Following the prefix set to zero. The maximum prefix length is 27. Following the prefix
is a mask of length 2^(32-prefix length) bits for IPv4 and is a mask of length 2^(32-prefix length) bits for IPv4 and
2^(128-prefix length) bits for IPv6. Each bit set to 1 represents a 2^(128-prefix length) bits for IPv6. Each bit set to 1 represents a
valid address. The address is the base IPv4 address plus the valid address. The address is the base IPv4 address plus the
skipping to change at page 27, line 15 skipping to change at page 27, line 15
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Those same addresses embedded in IPv6 would be encoded as follows: Those same addresses embedded in IPv6 would be encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0| |0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0| |1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 9 allows a more dense encoding of labels. The label prefix is Type 9 allows a more dense encoding of labels. The label prefix is
formatted as a base label value with the non-prefix low-order bits formatted as a base label value with the non-prefix low-order bits
set to zero. The maximum prefix (including leading zeros due to set to zero. The maximum prefix (including leading zeros due to
skipping to change at page 30, line 12 skipping to change at page 30, line 5
the label stack that was on the packet when it was received. Only the label stack that was on the packet when it was received. Only
one such object may appear. The purpose of the object is to allow one such object may appear. The purpose of the object is to allow
the upstream router to obtain the exact interface and label stack the upstream router to obtain the exact interface and label stack
information as it appears at the replying LSR. information as it appears at the replying LSR.
The Length is K + 4*N octets; N is the number of labels in the label The Length is K + 4*N octets; N is the number of labels in the label
stack. Values for K are found in the description of Address Type stack. Values for K are found in the description of Address Type
below. The Value field of a Downstream Mapping has the following below. The Value field of a Downstream Mapping has the following
format: format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must Be Zero | | Address Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) | | IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) | | Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
skipping to change at page 31, line 26 skipping to change at page 31, line 19
3.7. Errored TLVs 3.7. Errored TLVs
The following TLV is a TLV that MAY be included in an echo reply to The following TLV is a TLV that MAY be included in an echo reply to
inform the sender of an echo request of mandatory TLVs either not inform the sender of an echo request of mandatory TLVs either not
supported by an implementation or parsed and found to be in error. supported by an implementation or parsed and found to be in error.
The Value field contains the TLVs that were not understood, encoded The Value field contains the TLVs that were not understood, encoded
as sub-TLVs. as sub-TLVs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length | | Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
. . . .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. Reply TOS Byte TLV 3.8. Reply TOS Byte TLV
This TLV MAY be used by the originator of the echo request to request This TLV MAY be used by the originator of the echo request to request
that an echo reply be sent with the IP header TOS byte set to the that an echo reply be sent with the IP header TOS byte set to the
value specified in the TLV. This TLV has a length of 4 with the value specified in the TLV. This TLV has a length of 4 with the
following value field. following value field.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero | | Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Theory of Operation 4. Theory of Operation
An MPLS echo request is used to test a particular LSP. The LSP to be An MPLS echo request is used to test a particular LSP. The LSP to be
tested is identified by the "FEC Stack"; for example, if the LSP was tested is identified by the "FEC Stack"; for example, if the LSP was
set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC set up via LDP, and is to an egress IP address of 10.1.1.1, the FEC
skipping to change at page 33, line 37 skipping to change at page 33, line 27
labeled, the addition of labels shimmed above the MPLS echo request labeled, the addition of labels shimmed above the MPLS echo request
(using the Nil FEC) will prevent a router from forwarding such a (using the Nil FEC) will prevent a router from forwarding such a
packet out unlabeled interfaces. packet out unlabeled interfaces.
4.3. Sending an MPLS Echo Request 4.3. Sending an MPLS Echo Request
An MPLS echo request is a UDP packet. The IP header is set as An MPLS echo request is a UDP packet. The IP header is set as
follows: the source IP address is a routable address of the sender; follows: the source IP address is a routable address of the sender;
the destination IP address is a (randomly chosen) IPv4 address from the destination IP address is a (randomly chosen) IPv4 address from
the range 127/8 or IPv6 address from the range the range 127/8 or IPv6 address from the range
0:0:0:0:0:FFFF:127/104. The IP TTL is set to 1. The source UDP port 0:0:0:0:0:FFFF:7F00/104. The IP TTL is set to 1. The source UDP
is chosen by the sender; the destination UDP port is set to 3503 port is chosen by the sender; the destination UDP port is set to 3503
(assigned by IANA for MPLS echo requests). The Router Alert option (assigned by IANA for MPLS echo requests). The Router Alert option
MUST be set in the IP header. MUST be set in the IP header.
An MPLS echo request is sent with a label stack corresponding to the An MPLS echo request is sent with a label stack corresponding to the
FEC Stack being tested. Note that further labels could be applied FEC Stack being tested. Note that further labels could be applied
if, for example, the normal route to the topmost FEC in the stack is if, for example, the normal route to the topmost FEC in the stack is
via a Traffic Engineered Tunnel [RFC3209]. If all of the FECs in the via a Traffic Engineered Tunnel [RFC3209]. If all of the FECs in the
stack correspond to Implicit Null labels, the MPLS echo request is stack correspond to Implicit Null labels, the MPLS echo request is
considered unlabeled even if further labels will be applied in considered unlabeled even if further labels will be applied in
sending the packet. sending the packet.
skipping to change at page 34, line 23 skipping to change at page 34, line 15
In "ping" mode (end-to-end connectivity check), the TTL in the In "ping" mode (end-to-end connectivity check), the TTL in the
outermost label is set to 255. In "traceroute" mode (fault isolation outermost label is set to 255. In "traceroute" mode (fault isolation
mode), the TTL is set successively to 1, 2, and so on. mode), the TTL is set successively to 1, 2, and so on.
The sender chooses a Sender's Handle and a Sequence Number. When The sender chooses a Sender's Handle and a Sequence Number. When
sending subsequent MPLS echo requests, the sender SHOULD increment sending subsequent MPLS echo requests, the sender SHOULD increment
the Sequence Number by 1. However, a sender MAY choose to send a the Sequence Number by 1. However, a sender MAY choose to send a
group of echo requests with the same Sequence Number to improve the group of echo requests with the same Sequence Number to improve the
chance of arrival of at least one packet with that Sequence Number. chance of arrival of at least one packet with that Sequence Number.
The TimeStamp Sent is set to the time-of-day (in seconds and The TimeStamp Sent is set to the time-of-day in NTP format that the
microseconds) that the echo request is sent. The TimeStamp Received echo request is sent. The TimeStamp Received is set to zero.
is set to zero.
An MPLS echo request MUST have an FEC Stack TLV. Also, the Reply An MPLS echo request MUST have an FEC Stack TLV. Also, the Reply
Mode must be set to the desired reply mode; the Return Code and Mode must be set to the desired reply mode; the Return Code and
Subcode are set to zero. In the "traceroute" mode, the echo request Subcode are set to zero. In the "traceroute" mode, the echo request
SHOULD include a Downstream Mapping TLV. SHOULD include a Downstream Mapping TLV.
4.4. Receiving an MPLS Echo Request 4.4. Receiving an MPLS Echo Request
Sending an MPLS echo request to the control plane is triggered by one Sending an MPLS echo request to the control plane is triggered by one
of the following packet processing exceptions: Router Alert option, of the following packet processing exceptions: Router Alert option,
skipping to change at page 35, line 38 skipping to change at page 35, line 29
Label-stack-depth: the depth of label being verified. Initialized Label-stack-depth: the depth of label being verified. Initialized
to the number of labels in the received label to the number of labels in the received label
stack S. stack S.
FEC-stack-depth: depth of the FEC in the Target FEC Stack that FEC-stack-depth: depth of the FEC in the Target FEC Stack that
should be used to verify the current actual should be used to verify the current actual
label. Requires no initialization. label. Requires no initialization.
Best-return-code: contains the return code for the echo reply Best-return-code: contains the return code for the echo reply
packet as currently best known. As algorithm packet as currently best known. As the algorithm
progresses, this code may change depending on the progresses, this code may change depending on the
results of further checks that it performs. results of further checks that it performs.
Best-rtn-subcode: similar to Best-return-code, but for the Echo Best-rtn-subcode: similar to Best-return-code, but for the Echo
Reply Subcode. Reply Subcode.
FEC-status: result value returned by the FEC Checking FEC-status: result value returned by the FEC Checking
algorithm described in section 4.4.1. algorithm described in section 4.4.1.
/* Save receive context information */ /* Save receive context information */
skipping to change at page 36, line 48 skipping to change at page 36, line 39
Set Best-return-code to 11 ("No label entry at stack-depth") Set Best-return-code to 11 ("No label entry at stack-depth")
and Best-rtn-subcode to Label-stack-depth. Go to step 7 (Send and Best-rtn-subcode to Label-stack-depth. Go to step 7 (Send
Reply Packet). Reply Packet).
} }
Else { Else {
Retrieve the associated label operation from the corresponding Retrieve the associated label operation from the corresponding
NLFE and proceed to step 4 (Label Operation check). NHLFE and proceed to step 4 (Label Operation check).
} }
4. Label Operation Check 4. Label Operation Check
If the label operation is "Pop and Continue Processing" { If the label operation is "Pop and Continue Processing" {
/* Includes Explicit Null and Router Alert label cases */ /* Includes Explicit Null and Router Alert label cases */
Iterate to the next label by decrementing Label-stack-depth and Iterate to the next label by decrementing Label-stack-depth and
loop back to step 3 (Label Validation). loop back to step 3 (Label Validation).
} }
If the label operation is "Swap or Pop and Switch based on Popped If the label operation is "Swap or Pop and Switch based on Popped
skipping to change at page 38, line 39 skipping to change at page 38, line 34
/* Validate the Target FEC Stack in the received echo request. /* Validate the Target FEC Stack in the received echo request.
First determine FEC-stack-depth from the Downstream Mapping First determine FEC-stack-depth from the Downstream Mapping
TLV. This is done by walking through Stack-D (the Downstream TLV. This is done by walking through Stack-D (the Downstream
labels) from the bottom, decrementing the number of labels for labels) from the bottom, decrementing the number of labels for
each non-Implicit Null label, while incrementing FEC-stack- each non-Implicit Null label, while incrementing FEC-stack-
depth for each label. If the Downstream Mapping TLV contains depth for each label. If the Downstream Mapping TLV contains
one or more Implicit Null labels, FEC-stack-depth may be one or more Implicit Null labels, FEC-stack-depth may be
greater than Label-stack-depth. To be consistent with the greater than Label-stack-depth. To be consistent with the
above stack-depths, the bottom is considered to entry 1. above stack-depths, the bottom is considered to be entry 1.
*/ */
Set FEC-stack-depth to 0. Set i to Label-stack-depth. Set FEC-stack-depth to 0. Set i to Label-stack-depth.
While (i > 0 ) do { While (i > 0 ) do {
++FEC-stack-depth. ++FEC-stack-depth.
if Stack-D[FEC-stack-depth] != 3 (Implicit Null) if Stack-D[FEC-stack-depth] != 3 (Implicit Null)
--i. --i.
} }
If the number of labels in the FEC stack is greater than or
equal to FEC-stack-depth { If the number of FECs in the FEC stack is greater than or equal
to FEC-stack-depth {
Perform the FEC Checking procedure (see subsection 4.4.1 Perform the FEC Checking procedure (see subsection 4.4.1
below). below).
If FEC-status is 2, set Best-return-code to 10 ("Mapping for If FEC-status is 2, set Best-return-code to 10 ("Mapping for
this FEC is not the given label at stack-depth"). this FEC is not the given label at stack-depth").
If the return code is 1, set Best-return-code to FEC-return- If the return code is 1, set Best-return-code to FEC-return-
code and Best-rtn-subcode to FEC-stack-depth. code and Best-rtn-subcode to FEC-stack-depth.
} }
skipping to change at page 40, line 24 skipping to change at page 40, line 16
Label-L = extracted label from Stack-R at depth Label-L = extracted label from Stack-R at depth
Label-stack-depth. Label-stack-depth.
Loop back to step 6 (Egress FEC Validation). Loop back to step 6 (Egress FEC Validation).
} }
7. Send Reply Packet: 7. Send Reply Packet:
Send an MPLS echo reply with a Return Code of Best-return-code, Send an MPLS echo reply with a Return Code of Best-return-code,
and a Return Subcode of Best-rtn-subcode. Include any TLVs and a Return Subcode of Best-rtn-subcode. Include any TLVs
created during the above process. The procedures for sending the created during the above process. The procedures for sending the
echo reply are found in subsection 4.4.1. echo reply are found in subsection 4.5.
4.4.1. FEC Validation 4.4.1. FEC Validation
/* This subsection describes validation of an FEC entry within the /* This subsection describes validation of an FEC entry within the
Target FEC Stack and accepts an FEC, Label-L, and Interface-I. The Target FEC Stack and accepts an FEC, Label-L, and Interface-I. The
algorithm performs the following steps. */ algorithm performs the following steps. */
1. Two return values, FEC-status and FEC-return-code, are 1. Two return values, FEC-status and FEC-return-code, are
initialized to 0. initialized to 0.
skipping to change at page 43, line 47 skipping to change at page 43, line 36
to the control plane. A rate limiter SHOULD be applied to the well- to the control plane. A rate limiter SHOULD be applied to the well-
known UDP port defined below. known UDP port defined below.
Unsophisticated replay and spoofing attacks involving faking or Unsophisticated replay and spoofing attacks involving faking or
replaying MPLS echo reply messages are unlikely to be effective. replaying MPLS echo reply messages are unlikely to be effective.
These replies would have to match the Sender's Handle and Sequence These replies would have to match the Sender's Handle and Sequence
Number of an outstanding MPLS echo request message. A non-matching Number of an outstanding MPLS echo request message. A non-matching
replay would be discarded as the sequence has moved on, thus a spoof replay would be discarded as the sequence has moved on, thus a spoof
has only a small window of opportunity. However, to provide a has only a small window of opportunity. However, to provide a
stronger defense, an implementation MAY also validate the TimeStamp stronger defense, an implementation MAY also validate the TimeStamp
Sent by requiring and exact match on this field. Sent by requiring an exact match on this field.
To protect against unauthorized sources using MPLS echo request To protect against unauthorized sources using MPLS echo request
messages to obtain network information, it is RECOMMENDED that messages to obtain network information, it is RECOMMENDED that
implementations provide a means of checking the source addresses of implementations provide a means of checking the source addresses of
MPLS echo request messages against an access list before accepting MPLS echo request messages against an access list before accepting
the message. the message.
It is not clear how to prevent hijacking (non-delivery) of echo It is not clear how to prevent hijacking (non-delivery) of echo
requests or replies; however, if these messages are indeed hijacked, requests or replies; however, if these messages are indeed hijacked,
LSP ping will report that the data plane is not working as it should. LSP ping will report that the data plane is not working as it should.
 End of changes. 45 change blocks. 
54 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/