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
Support last call. /monique On 10/11/05 8:15 pm, "George Swallow" <swallow@cisco.com> wrote: > 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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|