The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Last-last call on LSR Self Test
This begins a one week last call on LSR Self Test,
draft-ietf-mpls-lsr-self-test-06.txt
The last call ends 17 NOV 2005 24:00 UTC.
The last call is limited to the changes made as a result of the previous
last call. Attached are the diffs from version 05 to 06.
...George
Section 1., para. 1:
OLD:
This document defines a means for a Label-Switching Router (LSR) to
verify that its dataplane is functioning for certain key Multi-Proto-
col Label Switching (MPLS) applications, including unicast forwarding
based on LDP [LDP] and traffic engineering tunnels based on [RSVP-
TE]. MPLS Echo Request and MPLS Echo Reply messages [LSP-Ping] are
extended to do the actual probing. The pings are sent to an upstream
neighbor, looped back through the LSR under test and intercepted, by
means of TTL expiration by a downstream neighbor. Extensions to LSP-
Ping [LSP-Ping] are defined to allow the down stream neighbor to
report the test results.
NEW:
This document defines a means for a Label-Switching Router (LSR) to
verify that its data plane is functioning for certain key Multi-Pro-
tocol Label Switching (MPLS) applications, including unicast forward-
ing based on LDP [LDP] and traffic engineering tunnels based on
[RSVP-TE]. MPLS Verification Request and MPLS Verification Reply
messages are defined to do the actual probing. The pings are sent to
an upstream neighbor, looped back through the LSR under test and
intercepted, by means of TTL expiration by a downstream neighbor.
Section 1., para. 2:
OLD:
In order to minimize the load on upstream LSRs a new loopback FEC is
defined. Receipt of a packet labeled with a loopback label will cause
the advertising LSR to pop the label off the label stack and send the
packet out the advertised interface.
NEW:
In order to minimize the load on upstream LSRs a loopback FEC Type is
defined. Labels advertised with this FEC Type are referred to as
loopback labels. Receipt of a packet labeled with a loopback label
will cause the advertising LSR to pop the label off the label stack
and send the packet out the advertised interface.
Section 1., para. 3:
OLD:
Note that use of a loopback allows an LSR to test label entries for
which the LSR is not currently some neighbor's next hop. In this way
label entries can be verified prior to the occurrence of a routing
change.
NEW:
Use of a loopback mechnism allows an LSR to test label entries which
are not currently in use. For example many LSRs advertise label map-
pings for all IPv4 routes to all of their neighbors. For some por-
tion of these their neighbor LSR is not currently upstream and the
label entry is not used. But if the neighbors best path to a desti-
nation changes, that route and the associated label entry will be
used. An LSR can loop traffic through a "non-upstream" LSR because
that LSR is acting only on the loopback label and not on the underly-
ing label associated with the actual FEC being tested. In this way
label entries can be verified prior to the occurrence of a routing
change.
Section 1., para. 4:
OLD:
Some routing protocls, most notably OSPF have no means of exchanging
the "Link Local Identifiers" used to identify unnumbered links and
components of bundled links. These test procedures can be used to
associate the neighbor's interfaces with the probing LSRs interfaces.
This is achieved by simply having the TTL of the MPLS Ping expire one
hop sooner, i.e. at the testing LSR itself.
NEW:
Some routing protocols, most notably OSPF have no means of exchanging
the "Link Local Identifiers" used to identify unnumbered links and
components of bundled links. These test procedures can be used to
associate the neighbor's interfaces with the probing LSRs interfaces.
This is achieved by simply having the TTL of the MPLS Ping expire one
hop sooner, i.e. at the testing LSR itself.
Section 2., para. 1:
OLD:
The Loopback FEC type is defined to enable an upstream neighbor to
assist in LSR self-testing at very low cost. This FEC causes the
loopback to occur in the dataplane without control plane involvement
beyond the initial LDP exchange and dataplane setup. The FEC also
carries information to indicate the desired encapsulation should it
be the only label in a received label stack. Values are defined for
IPv4 and IPv6.
NEW:
The Loopback FEC type is defined to enable an upstream neighbor to
assist in LSR self-testing at very low cost. This FEC causes the
loopback to occur in the dataplane without control plane involvement
beyond the initial LDP exchange and data-plane setup. The FEC also
carries information to indicate the desired encapsulation should it
be the only label in a received label stack. Values are defined for
IPv4 and IPv6.
Section 2.1., para. 3:
OLD:
Must be set to zero on transmission and ignored on receipt.
NEW:
MUST be set to zero on transmission and ignored on receipt.
Section 2.1., para. 6:
OLD:
Note that this type also indicates the encapsulation type for payloads
that have a label stack contain the one loopback label.
NEW:
Note that these type values also indicate the encapsulation (IPv4 or
IPv6) for payloads that have a label stack containing only a loopback
label.
Section 2.2., para. 1:
OLD:
It is RECOMMENDED that loopback labels only be distributed in
response to a Label Request message, irrespective of the label adver-
tisement mode of the LDP session. However it is recognized that in
certain cases such as OSPF with unnumbered links, the upstream LSR
may not have sufficiently detailed information of the neighbor's link
identifier to form the request. In these cases, the downstream LSR
will need to be configured to make unsolicited advertisements.
NEW:
It is RECOMMENDED that loopback labels only be distributed in
response to a Label Request message, irrespective of the label adver-
tisement mode of the LDP session. However it is recognized that in
certain cases such as OSPF with unnumbered links, the upstream LSR
may not have sufficiently detailed information of the neighbor's link
identifier to form the request. In these cases, the downstream LSR
MAY be configured to make unsolicited advertisements.
Section 3., para. 1:
OLD:
A self test operation involves three LSRs, the LSR doing the test, an
upstream neighbor and a downstream neighbor. We refer to these as
LSRs T, U, and D respectively. In order to minimize the processing
load on LSR-D, two new LSP Ping messages are defined, called the MPLS
Data Plane Verification Request and the MPLS Data Plane Verification
Reply. These messages are used to allow LSR-T to obtain the label
stack, address and interface information of LSR-D.
If FEC verification is required, the MPLS Echo Request and Reply mes-
sages are used.
NEW:
A self test operation involves three LSRs, the LSR doing the test, an
upstream neighbor and a downstream LSR. Upstream here is with
respect to the flow of the test (which in some cases could be differ-
ent than the normal sense of upstream in IP routing). We refer to
these as LSRs T, U, and D respectively. In order to minimize the
processing load on LSR-D, two new LSP Ping messages are defined,
called the MPLS Data Plane Verification Request and the MPLS Data
Plane Verification Reply. These messages are used to allow LSR-T to
obtain the label stack, address and interface information of LSR-D.
Section 3.1., para. 6:
OLD:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPLS Data Plane Verification Request message MAY contain the fol-
lowing objects:
NEW:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | MUST Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MPLS Data Plane Verification Request message MAY contain the fol-
lowing objects:
Section 3.1., para. 7:
OLD:
Type # Object
------ -----------
3 Pad
5 Vendor Enterprise Code
11 (provisional) IPv4 Reply-to Object
12 (provisional) IPv6 Reply-to Object
NEW:
Type # Object
------ -----------
3 Pad
10 Reply TOS Byte
11 (provisional) IPv4 Reply-to Address
12 (provisional) IPv6 Reply-to Address
64512-65535 Vendor Private TLVs
Section 3.1., para. 9:
OLD:
Type # Object
------ -----------
3 Pad
4 Error Code
5 Vendor Enterprise Code
7 IPv4 Interface and Label Stack Object
8 IPv6 Interface and Label Stack Object
NEW:
Type # Object
------ -----------
7 Interface and Label Stack
9 Errored TLVs
64512-65535 Vendor Private TLVs
Section 3.2., para. 1:
OLD:
MPLS Data Plane Verification Request messages MAY be sent to port
3503 as is used for [LSP-PING]. However to aid implementations that
wish to handle these messages at a lower level than MPLS Echo Request
messages another UDP port, tbd, is provided. Port tbd SHOULD be used
by default. The source UDP port, as in [LSP-PING] is chosen by the
sender.
NEW:
MPLS Data Plane Verification Request messages MAY be sent to port
3503 as is used for [LSP-PING]. However to aid implementations that
wish to handle these messages at a lower level than MPLS Echo Request
messages another UDP port, <tbd>, is provided. Port <tbd> SHOULD be
used by default. The source UDP port, as in [LSP-PING] is chosen by
the sender.
Section 3.2., para. 2:
OLD:
3.3. Reply-To Object
NEW:
3.3. Reply-To Address Object
Section 3.2., para. 4:
OLD:
3.3.1. IPv4 Reply-To Object
NEW:
3.3.1. IPv4 Reply-To Address Object
Section 3.2., para. 5:
OLD:
The length of an IPv4 Reply-To Object is 4 octets; the value field
has the following format:
NEW:
The length of an IPv4 Reply-to Address object is 4 octets; the value
field has the following format:
Section 3.2., para. 9:
OLD:
3.3.2. IPv6 Reply-To Object
NEW:
3.3.2. IPv6 Reply-To Address Object
Section 3.2., para. 10:
OLD:
The length of an IPv6 Reply-To Object is 16 octets; the value field
has the following format:
NEW:
The length of an IPv6 Reply-to Address object is 16 octets; the value
field has the following format:
Section 3.4., para. 2:
OLD:
The LSR creates an MPLS Data Plane Verification Request message and
includes a Data Plane Verification Object. Optionally a FEC Stack
TLV may be included. In this case an MPLS Echo Request Message MUST
be used.
NEW:
The LSR creates an MPLS Data Plane Verification Request message.
Section 3.4., para. 3:
OLD:
In normal use, the source address is set to an address belonging to
the LSR and the destination set to an address in the range of 127/8.
The incoming label stack (if any) is prepended to the packet. The
TTL of these labels and the packet header SHOULD be set to appropri-
ate values - 2 for those labels and/or header which will be processed
by this node when the packet is looped back; 1 for those labels
and/or header which will be carried through. Finally the loopback
label bound to the incoming interface is prepended to the packet. In
the case of an otherwise unlabeled packet the label's FEC MUST indi-
cate the appropriate IP version. The TTL is set such that it will
have the value of 3 on the wire.
NEW:
In normal use, the source address is set to an address belonging to
the LSR and the destination set to an address in the range of 127/8.
The incoming label stack (if any) is prepended to the packet. The
TTL of these labels and the packet header SHOULD be set to appropri-
ate values - 2 for those labels and/or header which will be processed
by this node when the packet is looped back; 1 for those labels
and/or header which will be carried through. Finally the loopback
label bound to the incoming interface is prepended to the packet. In
the case of an otherwise unlabeled packet the label's FEC MUST indi-
cate the appropriate IP version. The TTL is set such that it will
have the value of 3 on the wire.
Section 3.4., para. 5:
OLD:
In diagnostic situations, the source and destination addresses MAY be
set to any value. In this case, a Reply-to IPv4 or IPv6 Object MUST
be included. The IP TTL MUST be set to 1. The TTL of labels other
than the loopback label MUST be set to appropriate values - 2 for
those labels which will be process by this LSR when the packet is
looped back; 1 for those labels which will be carried through.
NEW:
In diagnostic situations, the source and destination addresses MAY be
set to any value. In this case, a Reply-to IPv4 or IPv6 Address
object MUST be included. The IP TTL MUST be set to 1. The TTL of
labels other than the loopback label MUST be set to appropriate val-
ues - 2 for those labels which will be process by this LSR when the
packet is looped back; 1 for those labels which will be carried
through.
Section 3.4., para. 6:
OLD:
In some MPLS deployments TTL hiding is used to make a providers net-
work appear as a single hop. That is the TTL in the imposed label
does not refect the TTL of the received packet. It is RECOMMENDED
that testing of label imposition SHOULD NOT be performed in such cir-
cumstances as the Echo Request will in most case travel multiple
hops.
NEW:
In some MPLS deployments TTL hiding is used to make a providers net-
work appear as a single hop. That is the TTL in the imposed label
does not reflect the TTL of the received packet. It is RECOMMENDED
that testing of label imposition SHOULD NOT be performed in such cir-
cumstances as the Verification Request will in most case travel mul-
tiple hops.
Section 3.5., para. 2:
OLD:
X then parses the packet to ensure that it is a well-formed packet,
and that the TLVs that are not marked "Ignore" are understood. If
not, X SHOULD send an MPLS echo reply with the Return Code set to
"Malformed echo request received" or "TLV not understood" (as appro-
priate), and the Subcode set to zero. In the latter case, the misun-
derstood TLVs (only) are included in the reply.
NEW:
X then parses the packet to ensure that it is a well-formed packet,
and that the TLVs that are not marked "Ignore" are understood. If
not, X SHOULD set the Return Code set to "Malformed echo request
received" or "TLV not understood" (as appropriate), and the Subcode
set to zero. In the latter case, the misunderstood TLVs (only) are
included in the reply.
Section 3.5., para. 3:
OLD:
If the echo request is good, X notes the interface I over which the
echo was received, and the label stack with which it came. If the
MPLS echo request contained a Downstream Verification object, then X
must format this information as a Downstream Verification object and
include it in its MPLS echo reply message.
NEW:
If the Verification Request is good, X MUST note the interface and
label stack of the received Verification Request and format this
information as a Downstream Verification object. This object is
included in the MPLS Verification Reply message. The Return Code and
Subcode MUST be set to zero, indicating "No return code".
Section 3.5., para. 4:
OLD:
The source address of the Reply message MUST be an address of the
replying LSR. If the request included a Reply-to IPv4 or IPv6
Object, the MPLS Data Plane Verification Reply message MUST be sent
to that address. Otherwise the Reply message is sent to the source
address of the Verification Request message.
NEW:
The source address of the Reply message MUST be an address of the
replying LSR. If the request included a Reply-to IPv4 or IPv6
Address object, the MPLS Data Plane Verification Reply message MUST
be sent to that address. Otherwise the Reply message is sent to the
source address of the Verification Request message.
Section 5., para. 4:
OLD:
LSP Ping Object Type 11 IPv4 Reply-to Object
LSP Ping Object Type 12 IPv6 Reply-to Object
NEW:
LSP Ping Object Type 11 IPv4 Reply-to Address
LSP Ping Object Type 12 IPv6 Reply-to Address
Section 7.2., para. 2:
OLD:
Authors' Addresses
NEW:
8. Authors' Addresses
Section 7.2., para. 11:
OLD:
January 2006
NEW:
April 2006
========================================================================
George Swallow Cisco Systems (978) 936-1398
1414 Massachusetts Avenue
Boxborough, MA 01719
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
|
|