draft-ietf-mpls-rfc6374-udp-return-path-01.txt   draft-ietf-mpls-rfc6374-udp-return-path-02.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: March 8, 2015 Cisco Systems Expires: March 29, 2015 Cisco Systems
September 4, 2014 September 25, 2014
RFC6374 UDP Return Path RFC6374 UDP Return Path
draft-ietf-mpls-rfc6374-udp-return-path-01 draft-ietf-mpls-rfc6374-udp-return-path-02
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 March 8, 2015. This Internet-Draft will expire on March 29, 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 3, line 49 skipping to change at page 3, line 49
~ Address ~ ~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type and Length fields are each 8 bits long. 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 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.
4. Theory of Operation 4. Theory of Operation
skipping to change at page 5, line 26 skipping to change at page 5, line 26
4.3. 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
the normal management and security considerations. The packet format the normal management and security considerations. The packet format
for the MPLS-PLDM response after the UDP header is as specified in for the MPLS-PLDM response after the UDP header is as specified in
[RFC6374]. As shown in Figure 1 the Associate Channel Header (ACH) [RFC6374]. As shown in Figure 1 the Associate Channel Header (ACH)
[RFC5586] is not incuded. The information provided by the ACH is not [RFC5586] is not incuded. The information provided by the ACH is not
needed since the correct binding between the Querry and Response needed since the correct binding between the Querry and Response
messages is achieved though the UDP Port and the Session Indentifier messages is achieved though the UDP Port and the Session Indentifier
contained in the RFC6374 message. contained in the RFC6374 message.
+----------------------------------------------------------+ +----------------------------------------------------------+
skipping to change at page 7, line 20 skipping to change at page 7, line 20
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.
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 has made an early allocation of a new Optional TLV type from
Delay Measurement TLV Object Registry contained within the g-ach- MPLS Loss/Delay Measurement TLV Object Registry contained within the
parameters registry set. g-ach-parameters registry set. IANA is requested to modify the
description text as shown below.
Code Description Reference Code Description Reference
TBD Return UDP Port [This] 131 UDP Return [This]
The TLV 131 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. References
9.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
9.2. Informative References
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010. 5921, July 2010.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
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
Siva Sivabalan Siva Sivabalan
Cisco Systems Cisco Systems
 End of changes. 10 change blocks. 
16 lines changed or deleted 19 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/