Movatterモバイル変換


[0]ホーム

URL:



MPLS                                                           S. BryantInternet-Draft                                                G. SwallowIntended status: Standards Track                            S. SivabalanExpires: September 3, 2015                                 Cisco Systems                                                           March 2, 2015RFC6374 over UDPdraft-bryant-mpls-rfc6374-over-udp-00Abstract   Indraft-bryant-mpls-synonymous-flow-labels the concept of MPLS   synonymous flow labels (SFL) was introduced and it was shown how they   could be used to supportRFC6374 loss measurements.  Indraft-bryant-mpls-sfl-control the request, lifetime management and withdrawal of   SFLs was described.  In this memo we show how these two protocols can   be run over UDP to support the operation ofRFC6374 in systems that   do not support the Generic Associated Channel Label (GAL) (RFC5586).Status of This Memo   This Internet-Draft is submitted in full conformance with the   provisions ofBCP 78 andBCP 79.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF).  Note that other groups may also distribute   working documents as Internet-Drafts.  The list of current Internet-   Drafts is athttp://datatracker.ietf.org/drafts/current/.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   This Internet-Draft will expire on September 3, 2015.Copyright Notice   Copyright (c) 2015 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.  Code Components extracted from this document mustBryant, et al.          Expires September 3, 2015               [Page 1]

Internet-DraftRFC6374 over UDP                  March 2015   include Simplified BSD License text as described in Section 4.e of   the Trust Legal Provisions and are provided without warranty as   described in the Simplified BSD License.Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .22.  Requirements Language . . . . . . . . . . . . . . . . . . . .33.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . . . .33.1.  Querier to Responder  . . . . . . . . . . . . . . . . . .34.  Manageability Considerations  . . . . . . . . . . . . . . . .45.  Security Considerations . . . . . . . . . . . . . . . . . . .46.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .47.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .58.  Normative References  . . . . . . . . . . . . . . . . . . . .5   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .51.  Introduction   Indraft-bryant-mpls-synonymous-flow-labels the concept of MPLS   synonymous flow labels (SFL) was introduced and it was shown how they   could be used to supportRFC6374 loss measurements.  Indraft-bryant-mpls-sfl-control the request, lifetime management and withdrawal of   SFLs was described.  In this memo we show how these two protocols can   be run over UDP to support the operation ofRFC6374 in systems that   do not support the Generic Associated Channel Label (GAL) [RFC5586].   The approach is to run an Associated Channel Header directly over UDP   using the ACH UDP port supplemented by addressing information carried   in the ACH payload.  This memo explains how the extension ofRFC6374   as described indraft-bryant-mpls-synonymous-flow-labels anddraft-bryant-mpls-sfl-control provide the necessary information to provide   mapping between theRFC6374 packet carried over UDP and the MPLS   construct being monitored, even when theRFC6374 protocol exchange is   entirely out of band relative to the Label Switched Path (LSP),   Virtual Private Network (VPN) or Pseudowire (PW) being instrumented.   The key to this is the decoupling between theRFC6374 message and the   data plane provided through the use of synonymous flow labels (SFL)   as described indraft-bryant-mpls-synonymous-flow-labels.   Nothing in this memo prevents the use of the ACH UDP port for other   types of Associated Channels, but the precise method of doing so is   outside the scope of this text.Bryant, et al.          Expires September 3, 2015               [Page 2]

Internet-DraftRFC6374 over UDP                  March 20152.  Requirements Language   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and   "OPTIONAL" in this document are to be interpreted as described in   [RFC2119].3.  Protocol Stack   The protocol stack is shown in Figure 1.  It consists of three   components, the UDP header, the ACH and either anRFC6374 message or   an SFL Control message.   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  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |    Source  Port               |       Destination Port        |  UDP  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |    Length                     |       Checksum                |  UDP  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |0 0 0 1|Version|   Reserved    |         Channel Type          |  ACH  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |                                                               |  |RFC6374 or SFL Control Payload with SFL TLVs           .  .                                                               .  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                 Figure 1:RFC6374 over UDP Protocol Stack3.1.  Querier to Responder   The following is rather laboured, but it is necessary to demonstrate   that all of the required mapping information is carried.   Consider the direction Querier to Responder forRFC6374 Messages.   The following explains the identifier mapping.   1.  Destination IP address (carried in the outer IP header (not       shown)).  This is used to identify the targetedRFC6374 Responder       to the IP network.   2.  Source IP address (carried in the outer IP header (not shown)).       This is used to identify the originatingRFC6374 Querier to theRFC6374 Responder in order for it to construct the return IP       packet.   3.  UDP Source Port used by theRFC6374 Responder to direct responses       to the correct Query process on theRFC6374 Querier.Bryant, et al.          Expires September 3, 2015               [Page 3]

Internet-DraftRFC6374 over UDP                  March 2015   4.  UDP Destination Port is used byRFC6374 Querier to direct the       message to the correct process on theRFC6374 Responder.   5.  IP and UDP source and destination information are reversed in the       usual way in the ACH Response messages from Responder back to       Querier.   6.  TheRFC6374 Session Identifier used by both Querier and Responder       to discriminate between multipleRFC6374 sessions running       concurrently between the two nodes.   7.  The SFL from the SFL TLV in theRFC6374 messages is used to       identify the MPLS label that is being instrumented.   8.  The SFL Control Protocol Session identifier used by both Querier       and Responder to discriminate between multipleRFC6374 sessions       running concurrently between the two nodes and used to bind the       SFL control protocol session to theRFC6374 session.   Note that a node running the SFL control protocol allocates a unique   SFL in response to each SFL request, and thus there is no ambiguity   as to which session between which source-destination pair a   particular label belongs.   Also note that there is no restriction on the use of the same SFL by   many nodes since it always known which node allocated it by reference   to items 1..8 in the list above.4.  Manageability Considerations   This may be provided in a future version of this document.5.  Security Considerations   Great care needs to be taken to ensure that the UDP packets defined   in this document do not enter the network from unauthorised sources.   This can be achieved by careful address management and the use of   appropriate access control at the network's IP entry points.6.  IANA Considerations   IANA is requested to allocate a UDP port from the user port range:   Service Name:  ACH over UDP   Port Number:  TBD   Descriptiopn  Transport of Associated Channel Headers over UDPBryant, et al.          Expires September 3, 2015               [Page 4]

Internet-DraftRFC6374 over UDP                  March 2015   Reference  This memo7.  Acknowledgements   TBD8.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic              Associated Channel",RFC 5586, June 2009.Authors' Addresses   Stewart Bryant   Cisco Systems   Email: stbryant@cisco.com   George Swallow   Cisco Systems   Email: swallow@cisco.com   Siva Sivabalan   Cisco Systems   Email: msiva@cisco.comBryant, et al.          Expires September 3, 2015               [Page 5]
Datatracker

draft-bryant-mpls-rfc6374-over-udp-00
Expired Internet-Draft (individual)

DocumentDocument typeExpired Internet-Draft (individual)
Expired & archived
This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process.
Select version
AuthorsStewart Bryant,George Swallow,Siva Sivabalan
Email authors
RFC stream (None)
Intended RFC status (None)
Other formats
Report a datatracker bug

[8]ページ先頭

©2009-2025 Movatter.jp