draft-ietf-mpls-rfc6374-udp-return-path-00.txt   draft-ietf-mpls-rfc6374-udp-return-path-01.txt 
MPLS S. Bryant MPLS S. Bryant
Internet-Draft S. Sivabalan Internet-Draft S. Sivabalan
Intended status: Standards Track S. Soni Intended status: Standards Track S. Soni
Expires: February 28, 2015 Cisco Systems Expires: March 8, 2015 Cisco Systems
August 27, 2014 September 4, 2014
RFC6374 UDP Return Path RFC6374 UDP Return Path
draft-ietf-mpls-rfc6374-udp-return-path-00 draft-ietf-mpls-rfc6374-udp-return-path-01
Abstract Abstract
This document specifies the proceedure to be used by the Packet Loss This document specifies the proceedure to be used by the Packet Loss
and Delay Measurement for MPLS Networks protocol defined in RFC6374 and Delay Measurement for MPLS Networks protocol defined in RFC6374
when sending and processing MPLS performance management out-of-band when sending and processing MPLS performance management out-of-band
responses for delay and loss measurements over an IP/UDP return path. responses for delay and loss measurements 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 28, 2015. This Internet-Draft will expire on March 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
This document describes how Packet Loss and Delay Measurement for This document describes how Packet Loss and Delay Measurement for
MPLS Networks protocol (MPLS-PLDM) [RFC6374] out-of-band responses MPLS Networks protocol (MPLS-PLDM) [RFC6374] out-of-band responses
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 a the distributed system that comprises the LSR as a whole. within the distributed system that comprises the Label Switching
In such systems the response may arrive via any interface in the LSR Router (LSR) as a whole. In such systems the response may arrive via
and need to internally forwarded to the processor tasked with any interface in the LSR and need to internally forwarded to the
handling the particular MPLS-PLDM measurement. Currently the MPLS- processor tasked with handling the particular MPLS-PLDM measurement.
PLDM protocol does not have any mechanism to deliver the PLDM Currently the MPLS-PLDM protocol does not have any mechanism to
Response message to particular node within a multi-CPU LSR. deliver the PLDM Response message to particular node within a multi-
CPU LSR.
The procedure described in this specification describes how the The procedure described in this specification describes how the
queryer requests delivery of the MPLS-PLDM response over IP to a queryer 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 reponse 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",
skipping to change at page 2, line 48 skipping to change at page 2, line 49
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 MUST use the IP address and UDP port in the URO to reply back to the
querier. Multiple UROs MAY be present in a MPLS-PLDM Query querier. Multiple UROs MAY be present in a MPLS-PLDM Query
indicating that an identical responses SHOULD be sent to each addess- indicating that an identical responses SHOULD be sent to each addess-
port pair. A responder MAY be designed or configured to only port pair. A responder MAY be designed or configured to only
transmit a single response, in which case the response MUST be sent transmit a single response, in which case the response MUST be sent
using the parameters specified in the first URO in the querry packet. using the parameters specified in the first URO in the querry packet.
The procedures defined in this document may be applied to both The procedures defined in this document may be applied to both
unidirectional tunnels and bidirectional LSPs. In this document, the unidirectional and bidirectional LSPs. In this document, the term
term bidirectional LSP includes the co-routed bidirectional LSP bidirectional LSP includes the co-routed bidirectional LSP defined in
defined in [RFC3945] and the associated bidirectional LSP that is [RFC3945] and the associated bidirectional LSP that is constructed
constructed from a pair of unidirectional LSPs (one for each from a pair of unidirectional LSPs (one for each direction) that are
direction) that are associated with one another at the LSP's ingress/ associated with one another at the LSP's ingress/egress points
egress points [RFC5654]. The mechanisms defined in this document can [RFC5654]. The mechanisms defined in this document can apply to both
apply to both IP/MPLS and the MPLS Transport Profile (MPLS-TP). IP/MPLS and to the MPLS Transport Profile (MPLS-TP)[RFC5654],
[RFC5921]
3.1. UDP Return Object 3.1. UDP Return Object
[Note to reviewers - to be deleted before publication - We considered NOTE TO RFC Editor please delete the following paragraph before
a number of approaches to the design. The first was to use the publication.
existing address object and a separate UDP object, but concern in the
WG was that there may be more than one collector that required this START DELETE
information, and the combined size of the two objects. The next
approach considered by the authors was to create a new object by Note to reviewers - We considered a number of approaches to the
appending a UDP port to the existing generalized address object. design. The first was to use the existing address object and a
However by noting that UDP is only likely to be sent over IP and that separate UDP object, but concern in the WG was that there may be more
it will be a long time before we design a third major version of IP than one collector that required this information, and the combined
we can compress the object either by having separate IPv4 and an IPv4 size of the two objects. The next approach considered by the authors
objects, or using the address length as the discriminator. The was to create a new object by appending a UDP port to the existing
object design below uses the latter approach. The resultant combined generalized address object. However by noting that UDP is only
UDP port + address object is thus the same size as the original likely to be sent over IP and that it will be a long time before we
address object.] design a third major version of IP we can compress the object either
by having separate IPv4 and an IPv4 objects, or using the address
length as the discriminator. The object design below uses the latter
approach. The resultant combined UDP port + address object is thus
the same size as the original address object.
END DELETE
The format of the UDP Return Object (URO) is as follows: The format of the UDP Return Object (URO) is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URO TLV Type | Length={6,18} | UDP-Destination-Port | | URO TLV Type | Length={6,18} | UDP-Destination-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~ ~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type and Length fields are each 8 bits long, and the Length field The Type and Length fields are each 8 bits long. The Length field
indicates the size in bytes of the remainder of the object (i.e. is indicates the size in bytes of the remainder of the object (i.e. is
the size of the address in bytes plus 2). When the address is IPv4 the size of the address in bytes plus 2). When the address is IPv4
the length field is thus 6 and when the address is IPv6 the length the length field is thus 6 and when the address is IPv6 the length
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 <TBD>. The UDP Return Object Type (URO TLV Type) has a value of <TBD>.
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].
skipping to change at page 4, line 11 skipping to change at page 4, line 18
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.
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 IP/
UDP encapsulation. UDP encapsulation.
When the MPLS-PLDM Response is requested out-of-band by setting 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 as received in the URO. specified destination IP address contained in the URO.
If the URO is expected but is not present in 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. If received over a bidirectional LSP, the NOT be processed further, and if posisble an "Error - Invalid
control code of the Response message MUST be set to "Error - Missing Message" ([RFC6374] Section 3.1) SHOULD be send to the Querrier and
TLV" and a Response SHOULD be sent over the reverse LSP. The receipt the operator notified via the management system (see Section 4.2 for
of such a mal-formed request SHOULD be notified to the operator rurther details.
through the management system, taking the normal precautions with
respect to the prevention of overload of the error reporting system.
4.1. Missing TLV
The control code "Missing TLV", which is classified as an Error
response code, indicates that the operation failed because one or
more required TLV Objects was not sent in the query message.
4.2. Sending an MPLS-PM Query 4.1. Sending an MPLS-PM 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-multiplexing of the response
for different measurement type, there MUST be a different UDP port for different measurement type, there MUST be a different UDP port
for each measurement type (Delay, loss and delay-loss combined). for 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.3. Receiving an MPLS PM Query Request 4.2. Receiving an MPLS PM 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
request is received, with the Control Code of the MPLS-PLDM Query set request 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 Address object or the
URO is missing, the Query SHOULD be dropped in the case of a URO is missing, the Query SHOULD be dropped in the case of a
unidirectional LSP. If both these TLVs are missing on a unidirectional LSP. If both these TLVs are missing on a
bidirectional LSP, the control code of Response message should set to bidirectional LSP, the control code of Response message should set to
"Invalid Message" and the response SHOULD be sent over the reverse 0x1C indicating "Error - Invalid Message" ([RFC6374] Section 3.1) and
LSP. The receipt of such a mal-formed request SHOULD be notified to the response SHOULD be sent over the reverse LSP. The receipt of
the operator through the management system, taking the normal such a mal-formed request SHOULD be notified to the operator through
precautions with respect to the prevention of overload of the error the management system, taking the normal precautions with respect to
reporting system. the prevention of overload of the error reporting system.
4.4. Sending an MPLS-PM Response 4.3. Sending an MPLS-PM 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 MUST be
copied from the URO. The source IP address and the source UDP port copied from the URO. The source IP address and the source UDP port
of Response packet is left to discretion of the Responder subject to of Response packet is left to discretion of the Responder subject to
skipping to change at page 6, line 27 skipping to change at page 6, line 27
| 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.5. Receiving an MPLS-PM Response 4.4. Receiving an MPLS-PM 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 [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,
skipping to change at page 7, line 24 skipping to change at page 7, line 23
of access control lists and firewalls. of access control lists and firewalls.
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 7. IANA Considerations
IANA is requested to assign a new Optional TLV type from MPLS Loss/ IANA is requested to assign a new Optional TLV type from MPLS Loss/
Delay Measurement TLV Object Registry contained within the g-ach- Delay Measurement TLV Object Registry contained within the g-ach-
parameters registry set. parameters registry set.
Code Description Reference Code Description Reference
TBD Return UDP Port [This] TBD Return UDP Port [This]
The TLV 131 is recommended. The TLV 131 is recommended.
IANA is requested to assign a new response code in the MPLS Loss/
Delay Measurement Control Code Registry contained within the g-ach-
parameters registry set.
Code Description Reference
TBD Missing TLV [This]
The response code 0x1E is recommended.
8. Acknowledgements 8. 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, and Jeffrey Zhang for their review comments. Mustapha Aissaoui, and Jeffrey Zhang for their review comments.
We thank all who have reviewed this text and provided feedback. We thank all who have reviewed this text and provided feedback.
9. Normative References 9. Normative References
skipping to change at page 8, line 19 skipping to change at page 8, line 9
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile", and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009. RFC 5654, September 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010.
[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, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
Authors' Addresses Authors' Addresses
Stewart Bryant Stewart Bryant
Cisco Systems Cisco Systems
Email: stbryant@cisco.com Email: stbryant@cisco.com
 End of changes. 20 change blocks. 
65 lines changed or deleted 62 lines changed or added

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