draft-ietf-mpls-rfc6374-udp-return-path-04.txt   draft-ietf-mpls-rfc6374-udp-return-path-05.txt 
MPLS S. Bryant MPLS S. Bryant
Internet-Draft S. Sivabalan Internet-Draft Independent
Intended status: Standards Track S. Soni Intended status: Standards Track S. Sivabalan
Expires: February 27, 2016 Cisco Systems Expires: October 9, 2016 S. Soni
August 26, 2015 Cisco Systems
April 7, 2016
RFC6374 UDP Return Path RFC6374 UDP Return Path
draft-ietf-mpls-rfc6374-udp-return-path-04 draft-ietf-mpls-rfc6374-udp-return-path-05
Abstract Abstract
This document specifies the procedure to be used by the Packet Loss RFC6374 defines a protocol for Packet Loss and Delay Measurement for
and Delay Measurement for MPLS Networks protocol defined in RFC6374 MPLS networks (MPLS-PLDM). This document specifies the procedures to
when sending and processing MPLS performance management out-of-band be used when sending and processing out-of-band MPLS performance
responses for delay and loss measurements over an IP/UDP return path. management responses over an IP/UDP return path.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 27, 2016. This Internet-Draft will expire on October 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at page 2, line 21
can be delivered to the querier using UDP/IP. can be delivered to the querier using UDP/IP.
The use of UDP may be required to support data path management such The use of UDP may be required to support data path management such
as passage through firewalls, or to provide the necessary as passage through firewalls, or to provide the necessary
multiplexing needed in bistatic operation where the querier and the multiplexing needed in bistatic operation where the querier and the
collector are not co-located and the collector is gathering the collector are not co-located and the collector is gathering the
response information for a number of responders. In a highly scaled response information for a number of responders. In a highly scaled
system some MPLS-PLDM sessions may be off-loaded to a specific node system some MPLS-PLDM sessions may be off-loaded to a specific node
within the distributed system that comprises the Label Switching within the distributed system that comprises the Label Switching
Router (LSR) as a whole. In such systems the response may arrive via Router (LSR) as a whole. In such systems the response may arrive via
any interface in the LSR and need to internally forwarded to the any interface in the LSR and need to be forwarded internally to the
processor tasked with handling the particular MPLS-PLDM measurement. processor tasked with handling the particular MPLS-PLDM measurement.
Currently the MPLS-PLDM protocol does not have any mechanism to Currently the MPLS-PLDM protocol does not have any mechanism to
deliver the PLDM Response message to particular node within a multi- deliver the PLDM Response message to a particular node within a
CPU LSR. multi-CPU LSR.
The procedure described in this specification describes how the The procedure described in this specification describes how the
querier requests delivery of the MPLS-PLDM response over IP to a querier requests delivery of the MPLS-PLDM response over IP to a
dynamic UDP port. It makes no other changes to the protocol and thus dynamic UDP port. It makes no other changes to the protocol and thus
does not affect the case where the reponse is delivered over a MPLS does not affect the case where the response is delivered over a MPLS
Associated Channel [RFC5586]. Associated Channel [RFC5586].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Solution Overview 3. Solution Overview
This document specifies that, unless configured otherwise, if a UDP This document specifies that, unless configured otherwise, if a UDP
Return Object (URO) is present in a MPLS-PLDM Query, the responder Return Object (URO) is present in a MPLS-PLDM Query, the responder
MUST use the IP address and UDP port in the URO to reply back to the SHOULD use the IP address and UDP port in the URO to reply back to
querier. Multiple UROs MAY be present in a MPLS-PLDM Query the querier. The querier MAY include multiple UROs in a MPLS-PLDM
indicating that an identical responses SHOULD be sent to each Query indicating to the responder that an identical responses SHOULD
address-port pair. A responder MAY be designed or configured to only be sent to each address-port pair. A responder MAY be designed or
transmit a single response, in which case the response MUST be sent configured to only transmit a single response, in which case the
using the parameters specified in the first URO in the query packet. response MUST be sent using the parameters specified in the first URO
in the query packet that it is able to use (see Section 4.3).
The procedures defined in this document may be applied to both The procedures defined in this document may be applied to both
unidirectional and bidirectional LSPs. In this document, the term unidirectional and bidirectional LSPs. In this document, the term
bidirectional LSP includes the co-routed bidirectional LSP defined in bidirectional LSP includes the co-routed bidirectional LSP defined in
[RFC3945] and the associated bidirectional LSP that is constructed [RFC3945] and the associated bidirectional LSP that is constructed
from a pair of unidirectional LSPs (one for each direction) that are from a pair of unidirectional LSPs (one for each direction) that are
associated with one another at the LSP's ingress/egress points associated with one another at the LSP's ingress/egress points
[RFC5654]. The mechanisms defined in this document can apply to both [RFC5654]. The mechanisms defined in this document can apply to both
IP/MPLS and to the MPLS Transport Profile (MPLS-TP)[RFC5654], IP/MPLS and to the MPLS Transport Profile (MPLS-TP)[RFC5654],
[RFC5921] [RFC5921]
skipping to change at page 4, line 10 skipping to change at page 4, line 14
field is thus 18. The length field therefore acts as both the TLV field is thus 18. The length field therefore acts as both the TLV
parsing parameter and the address family type indicator. parsing parameter and the address family type indicator.
The UDP Return Object Type (URO TLV Type) has a value of 131. The UDP Return Object Type (URO TLV Type) has a value of 131.
The UDP Destination Port is a UDP Destination port as specified in The UDP Destination Port is a UDP Destination port as specified in
[RFC0768]. [RFC0768].
The Address is either an IPv4 or an IPv6 address. The Address is either an IPv4 or an IPv6 address.
The URO MUST NOT appear in a response. The URO MUST NOT appear in a response and MUST be ignored if it is
found to be present.
To prevent any ambiguity as to which address the responder needs to
reply to, an MPLS-PLDM Query message containing a URO MUST NOT
include an RFC6374 Return Address TLV (TLV 1). Additionally, the
method of constructing the return address from the Source Address TLV
(TLV 130) described in Section 3.5.2 of RFC6374 MUST NOT be used to
construct a Response to a Query message that contains a URO.
4. Theory of Operation 4. Theory of Operation
This document defines the UDP Return Object to enable the MPLS-PLDM This document defines the UDP Return Object to enable the MPLS-PLDM
querier to specify the return path for the MPLS-PLDM reply using IP/ querier to specify the return path for the MPLS-PLDM reply using UDP/
UDP encapsulation. IP encapsulation.
When the MPLS-PLDM Response is requested out-of-band by setting the When the MPLS-PLDM Response is requested out-of-band by setting the
Control Code of the MPLS-PLDM query to "Out-of-band Response Control Code of the MPLS-PLDM query to "Out-of-band Response
Requested", and the URO is present, the responder SHOULD send the Requested", and the URO is present, the responder SHOULD send the
response back to querier on the specified destination UDP port at the response back to querier on the specified destination UDP port at the
specified destination IP address contained in the URO. specified destination IP address contained in the URO.
If the URO is expected but is not present in a query message and an If the URO is expected but is not present in a query message and an
MPLS-PLDM Response is requested out-of-band, the query message MUST MPLS-PLDM Response is requested out-of-band, the query message MUST
NOT be processed further, and if possible an "Error - Invalid NOT be processed further, and if possible an "Error - Invalid
Message" ([RFC6374] Section 3.1) SHOULD be send to the querier and Message" ([RFC6374] Section 3.1) SHOULD be send to the querier and
the operator notified via the management system (see Section 4.2 for the operator notified via the management system (see Section 4.2 for
further details. further details.
4.1. Sending an MPLS-PM Query 4.1. Sending an MPLS-PLDM Query
When sending an MPLS-PLDM query message, in addition to the rules and When sending an MPLS-PLDM query message, in addition to the rules and
procedures defined in [RFC6374]; the Control Code of the MPLS-PLDM procedures defined in [RFC6374]; the Control Code of the MPLS-PLDM
query MUST be set to "Out-of-band Response Requested", and a URO MUST query MUST be set to "Out-of-band Response Requested", and a URO MUST
be carried in the MPLS-PLDM query message. be carried in the MPLS-PLDM query message.
If the querier uses the UDP port to de-multiplexing of the response If the querier uses the UDP port to de-multiplex the response for
for different measurement type, there MUST be a different UDP port different measurement type, there MUST be a different UDP port for
for each measurement type (Delay, loss and delay-loss combined). each measurement type (Delay, loss and delay-loss combined).
An implementation MAY use multiple UDP ports for same measurement An implementation MAY use multiple UDP ports for same measurement
type to direct the response to the correct management process in the type to direct the response to the correct management process in the
LSR. LSR.
4.2. Receiving an MPLS PM Query Request 4.2. Receiving an MPLS PLDM Query Request
The processing of MPLS-PLDM query messages as defined in [RFC6374] The processing of MPLS-PLDM query messages as defined in [RFC6374]
applies in this document. In addition, when an MPLS-PLDM query applies in this document. In addition, when an MPLS-PLDM query
message is received, with the control code of the MPLS-PLDM query set message is received, with the control code of the MPLS-PLDM query set
to "Out-of-band Response Requested" with a URO present, then the to "Out-of-band Response Requested" with a URO present, then the
responder SHOULD use that IP address and UDP port to send MPLS-PLDM responder SHOULD use that IP address and UDP port to send MPLS-PLDM
response back to querier. response back to querier.
If an Out-of-band response is requested and the Address object or the If an Out-of-band response is requested and the URO is missing, the
URO is missing, the query SHOULD be dropped in the case of a query SHOULD be dropped in the case of a unidirectional LSP. If the
unidirectional LSP. If both these TLVs are missing on a TLV is missing on a bidirectional LSP, the control code of the
bidirectional LSP, the control code of Response message should set to Response message SHOULD set to 0x1C indicating "Error - Invalid
0x1C indicating "Error - Invalid Message" ([RFC6374] Section 3.1) and Message" ([RFC6374] Section 3.1) and the response SHOULD be sent over
the response SHOULD be sent over the reverse LSP. The receipt of the reverse LSP. The receipt of such a mal-formed request SHOULD be
such a mal-formed request SHOULD be notified to the operator through notified to the operator through the management system, taking the
the management system, taking the normal precautions with respect to normal precautions with respect to the prevention of overload of the
the prevention of overload of the error reporting system. error reporting system.
4.3. Sending an MPLS-PM Response 4.3. Sending an MPLS-PLDM Response
As specified in [RFC6374] the MPLS-PLDM Response can be sent over As specified in [RFC6374] the MPLS-PLDM Response can be sent over
either the reverse MPLS LSP for a bidirectional LSP or over an IP either the reverse MPLS LSP for a bidirectional LSP or over an IP
path. It MUST NOT be sent other than in response to an MPLS-PLDM path. It MUST NOT be sent other than in response to an MPLS-PLDM
query message. query message.
When the requested return path is an IP forwarding path and this When the requested return path is an IP forwarding path and this
method is in use, the destination IP address and UDP port MUST be method is in use, the destination IP address and UDP port is copied
copied from the URO. The source IP address and the source UDP Port from the URO. The source IP address and the source UDP Port of the
of Response packet is left to discretion of the Responder subject to Response packet is left to discretion of the responder subject to the
the normal management and security considerations. The packet format normal management and security considerations. If the querier has
for the MPLS-PLDM response after the UDP header is as specified in included URO(s) for only one IP address family and a return path of
[RFC6374]. As shown in Figure 1 the Associate Channel Header (ACH) that type is not available, then the query message MUST be discarded,
[RFC5586] is not included. The information provided by the ACH is and the operator SHOULD be informed of the error through the
not needed since the correct binding between the query and response management system using the normal rate limited approach. If the
messages is achieved though the UDP Port and the session indentifier responder is configured to only respond with a single response, and a
contained in the RFC6374 message. path using the IP address family in the first URO is not available,
the responder MAY search the UROs for the first URO specifying a
return address family for which it does have a path and use the
parameters in that URO to respond. If the responder is designed or
configured not to search for a URO that it can respond to, then the
operator SHOULD be informed of the error through the management
system using the normal rate limited approach.
The packet format for the MPLS-PLDM response after the UDP header is
as specified in [RFC6374]. As shown in Figure 1 the Associate
Channel Header (ACH) [RFC5586] is not included. The information
provided by the ACH is not needed since the correct binding between
the query and response messages is achieved though the UDP Port and
the session indentifier contained in the RFC6374 message.
+----------------------------------------------------------+ +----------------------------------------------------------+
| IP Header | | IP Header |
. Source Address = Responders IP Address | . Source Address = Responders IP Address |
. Destination Address = URO.Address | . Destination Address = URO.Address |
. Protocol = UDP . . Protocol = UDP .
. . . .
+----------------------------------------------------------+ +----------------------------------------------------------+
| UDP Header | | UDP Header |
. Source Port = As chosen by Responder . . Source Port = As chosen by Responder .
skipping to change at page 6, line 27 skipping to change at page 6, line 37
| Message as specified in RFC6374 | | Message as specified in RFC6374 |
. . . .
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 1: Response packet Format Figure 1: Response packet Format
If the return path is an IP path, only one-way delay or one-way loss If the return path is an IP path, only one-way delay or one-way loss
measurement can be carried out. In this case timestamps 3 and 4 MUST measurement can be carried out. In this case timestamps 3 and 4 MUST
be zero as specified in [RFC6374]. be zero as specified in [RFC6374].
4.4. Receiving an MPLS-PM Response 4.4. Receiving an MPLS-PLDM Response
If the response was received over UDP/IP and an out-of-band response If the response was received over UDP/IP and an out-of-band response
was expected, the Response message SHOULD be directed to the was expected, the Response message SHOULD be directed to the
appropriate measurement process as determined by the destination UDP appropriate measurement process as determined by the destination UDP
Port, and processed using the corresponding measurement type Port, and processed using the corresponding measurement type
procedure specified in [RFC6374]. procedure specified in F [RFC6374].
If the Response was received over UDP/IP and an out-of-band response If the Response was received over UDP/IP and an out-of-band response
was not requested, that response should be dropped and the event was not requested, that response SHOULD be dropped and the event
SHOULD be notified to the operator through the management system, SHOULD be notified to the operator through the management system,
taking the normal precautions with respect to the prevention of taking the normal precautions with respect to the prevention of
overload of the error reporting system. overload of the error reporting system.
5. Manageability Considerations 5. Congestion Considerations
This protocol MUST be run in accordance the guidance provided in
[RFC5405]. As advised in section 3.2.1 of RFC5405, operators that
wish to run this protocol at rates in excess of one packet per three
seconds need to ensure that the MPLS path being monitored and any IP
path that may be used to carry the response are provisioned such that
there is a negligible chance of this protocol causing congestion.
Additionally, if a significant number of response packets are lost,
the querier MUST reduce the sending rate to a point where there is a
negligible chance that this protocol is contributing to network
congestion. The operator should also take precautions that response
packets do not leak out of the network domain being used and cause
congestion elsewhere. If a default IP address is configured by the
equipment vendor, this MUST be an address known to contain the
response packet within the responder, such as the IPv4 localhost
address [RFC6890] or the IPv6 loopback address [RFC4291]. A
responder receiving a query specifying this as a return address, and
not being configured to expect such a return address*, SHOULD notify
the operator in a suitably rate limited manner.
6. Manageability Considerations
The manageability considerations described in Section 7 of [RFC6374] The manageability considerations described in Section 7 of [RFC6374]
are applicable to this specification. Additional manageability are applicable to this specification. Additional manageability
considerations are noted within the elements of procedure of this considerations are noted within the elements of procedure of this
document. document.
Nothing in this document precludes the use of a configured UDP/IP Nothing in this document precludes the use of a configured UDP/IP
return path in a deployment in which configuration is preferred to return path in a deployment in which configuration is preferred to
signalling. In these circumstances the URO MAY be omitted from the signalling. In these circumstances the URO MAY be omitted from the
MPLS-PLDM messages. MPLS-PLDM messages.
6. Security Considerations 7. Security Considerations
The MPLS-PLDM system is not intended to be deployed on the public The MPLS-PLDM system is not intended to be deployed on the public
Internet. It is intended for deployment in well managed private and Internet. It is intended for deployment in well managed private and
service provider networks. The security considerations described in service provider networks. The security considerations described in
Section 8 of [RFC6374] are applicable to this specification and the Section 8 of [RFC6374] are applicable to this specification and the
reader's attention is drawn to the last two paragraphs. reader's attention is drawn to the last two paragraphs.
Cryptographic measures may be enhanced by the correct configuration Cryptographic measures may be enhanced by the correct configuration
of access control lists and firewalls. of access control lists and firewalls.
To prevent the use of this protocol as a reflection attack vector,
the operator should ensure that the IP address in the URO addresses a
system that is expecting to act as a receiver of PLDM responses.
There is no additional exposure of information to pervasive There is no additional exposure of information to pervasive
monitoring systems observing LSPs that are being monitored. monitoring systems observing LSPs that are being monitored.
7. IANA Considerations 8. IANA Considerations
IANA has made an early allocation of a new Optional TLV type from IANA has made an early allocation of a new Optional TLV type from
MPLS Loss/Delay Measurement TLV Object Registry contained within the MPLS Loss/Delay Measurement TLV Object Registry contained within the
Generic Associated Channel (G-ACh) Parameters registry set. IANA is Generic Associated Channel (G-ACh) Parameters registry set. IANA is
requested to modify the description text as shown below. requested to modify the description text as shown below.
Code Description Reference Code Description Reference
131 UDP Return [This] 131 UDP Return [This]
8. Acknowledgements 9. Acknowledgements
We acknowledge the contribution of Joseph Chin and Rakesh Gandhi, We acknowledge the contribution of Joseph Chin and Rakesh Gandhi,
both with Cisco Systems. We thank Loa Andersson, Eric Osborne, both with Cisco Systems. We thank Loa Andersson, Eric Osborne,
Mustapha Aissaoui, Jeffrey Zhang and Ross Callon for their review Mustapha Aissaoui, Jeffrey Zhang and Ross Callon for their review
comments. comments.
We thank all who have reviewed this text and provided feedback. We thank all who have reviewed this text and provided feedback.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004, DOI 10.17487/RFC3945, October 2004,
<http://www.rfc-editor.org/info/rfc3945>. <http://www.rfc-editor.org/info/rfc3945>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
DOI 10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, "MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009, DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>. <http://www.rfc-editor.org/info/rfc5586>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <http://www.rfc-editor.org/info/rfc5654>. September 2009, <http://www.rfc-editor.org/info/rfc5654>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>. <http://www.rfc-editor.org/info/rfc6374>.
9.2. Informative References [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
10.2. Informative References
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>. <http://www.rfc-editor.org/info/rfc5921>.
Authors' Addresses Authors' Addresses
Stewart Bryant Stewart Bryant
Cisco Systems Independent
Email: stbryant@cisco.com Email: stewart.bryant@gmail.com
Siva Sivabalan Siva Sivabalan
Cisco Systems Cisco Systems
Email: msiva@cisco.com Email: msiva@cisco.com
Sagar Soni Sagar Soni
Cisco Systems Cisco Systems
Email: sagsoni@cisco.com Email: sagsoni@cisco.com
 End of changes. 31 change blocks. 
61 lines changed or deleted 123 lines changed or added

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