Internet DRAFT - draft-frost-mpls-test-session

draft-frost-mpls-test-session






MPLS                                                            D. Frost
Internet-Draft                                                 S. Bryant
Intended status: Standards Track                           Cisco Systems
Expires: April 15, 2013                                 October 12, 2012


      MPLS Generic Associated Channel (G-ACh) Test Session Control
                    draft-frost-mpls-test-session-00

Abstract

   RFC 6374 defines procedures for packet loss and throughput
   measurement in MPLS networks.  Some forms of measurement rely on the
   existence of a stream of test messages that flows between measurement
   points, from which the loss and throughput characteristics of the
   underlying data channel are inferred.  This document presents
   procedures for the establishment and maintenance of such test
   sessions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 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 at http://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 April 15, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 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 must
   include Simplified BSD License text as described in Section 4.e of



Frost & Bryant           Expires April 15, 2013                 [Page 1]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Simple Session Control Protocol  . . . . . . . . . . . . . . .  4
     3.1.  Message Format . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  TLV Objects  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Session Setup  . . . . . . . . . . . . . . . . . . . . . .  9
     3.4.  Session Maintenance and Release  . . . . . . . . . . . . .  9
   4.  Test Session Parameters  . . . . . . . . . . . . . . . . . . . 10
     4.1.  Destination Test Identifier  . . . . . . . . . . . . . . . 10
     4.2.  Source Test Identifier . . . . . . . . . . . . . . . . . . 11
     4.3.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  Path Type  . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.5.  Payload Size Range . . . . . . . . . . . . . . . . . . . . 13
     4.6.  Maximum Transmission Rate  . . . . . . . . . . . . . . . . 13
   5.  Test Session Control . . . . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Allocation of Associated Channel Types . . . . . . . . . . 15
     7.2.  Creation of MPLS Simple Session Control Protocol TLV
           Registry . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.3.  Creation of MPLS Simple Session Control Protocol
           Session Type Registry  . . . . . . . . . . . . . . . . . . 15
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16



















Frost & Bryant           Expires April 15, 2013                 [Page 2]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


1.  Introduction

   Procedures and protocol messages for packet loss, delay, and
   throughput measurement in MPLS networks are documented in [RFC6374].
   Packet loss measurement, in that document, is classified as either
   direct or inferred: direct measurement is based on comparing transmit
   and receive counters for all data-plane traffic flowing over the
   channel, while inferred measurement is based on comparing the
   equivalent counters for a distinct stream of test traffic.
   Similarly, out-of-service throughput measurement entails validating
   the data-plane capacity of a channel by generating a stream of test
   traffic at a rate that meets or exceeds the expected capacity.

   The Loss Measurement (LM) protocol defined in RFC 6374 relies on the
   existence of a test traffic stream when used to conduct inferred LM
   or out-of-service throughput measurement.  This document defines
   procedures for the setup and control of such test streams via the
   MPLS Generic Associated Channel (G-ACh) [RFC5586].

1.1.  Terminology

   Term  Definition
   ----- -------------------------------
   G-ACh Generic Associated Channel
   LM    Loss Measurement
   SSCP  Simple Session Control Protocol
   TLV   Type-Length-Value

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Overview

   The objective is for a device acting as an LM querier to establish a
   test traffic stream to the LM responder in advance of initiating the
   LM session; this stream can then serve as the target of the LM
   operation, persisting until the operation is finished.  Test session
   setup and maintenance proceeds according to the following process:

   1.  The querier determines the desired parameters for the test
       session, encodes them in a setup message as specified later in
       this document, and sends it to the responder.  This message is
       transmitted periodically until either a response is forthcoming
       or a timeout occurs.



Frost & Bryant           Expires April 15, 2013                 [Page 3]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   2.  The responder, upon receiving the test session parameters, either
       accepts or rejects them.  In either case, it formulates a
       response and sends it to the querier.  The response indicates
       whether the session is accepted or rejected and, in the latter
       case, parameters that the responder considers acceptable.  If the
       session was accepted, it is now considered "alive" at the
       responder, which maintains state for it until it times out or is
       explicitly released.

   3.  The querier, upon receiving the responder's message, knows
       whether the test session is now active.  If not, it can retry the
       attempt using parameters the responder has indicated are
       acceptable.  If so, it now does three things: it begins sending
       test traffic; it periodically sends a message refreshing/
       verifying the test session state; and it initiates an LM session
       that targets this test session.

   4.  The querier, when finished with the measurement operation,
       terminates the LM session, ceases sending test traffic, and sends
       an advisory message to the responder that the test session has
       ended.

   In the remainder of this document the term "querier" is replaced by
   "initiator" in the context of test session control.


3.  Simple Session Control Protocol

   This document defines a new G-ACh protocol and associated Channel
   Type:

   Protocol                           Channel Type
   ---------------------------------- ------------
   Simple Session Control Protocol    0xXXXX

   For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV
   Header defined in [RFC5586].

   The Simple Session Control Protocol (SSCP) is a minimal "skeleton
   protocol" for the setup and control of point-to-point "sessions" over
   the G-ACh, where a session is defined abstractly as an initial
   agreement of application-specific parameters between the initiator
   and responder, followed by some form of state that is maintained
   between the two endpoints until either a timeout occurs or the
   session is explicitly released.

   The only SSCP application discussed in this document is that of
   measurement test stream control.  However, the SSCP has been defined



Frost & Bryant           Expires April 15, 2013                 [Page 4]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   in a general form with the view that it may have other future
   applications.

3.1.  Message Format

   The following figure shows the format of an SSCP message, which
   follows the Associated Channel Header (ACH):

        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| Resv  | Control Code  |        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Initiator Session Identifier (ISI)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Responder Session Identifier (RSI)           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                           TLV Block                           ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            SSCP Message Format

   Fields in this document shown as Reserved or Resv are reserved for
   future specification and MUST be set to zero.  All integer values for
   fields defined in this document SHALL be encoded in network byte
   order.

   In this format, the Version field indicates the protocol version and
   is currently set to 0.  The Message Length field indicates the size
   in octets of this message (i.e. of the portion of the packet that
   follows the Associated Channel Header).  The Initiator Session
   Identifier (ISI) and Responder Session Identifier (RSI) fields
   identify the specific session to which this message belongs, via
   locally-significant tags allocated by the initiator and the responder
   respectively.

   The Control Code indicates whether this message is querying,
   initiating, refreshing, releasing, accepting, or rejecting a session.
   The first four values are used by the initiator, the last two by the
   responder:











Frost & Bryant           Expires April 15, 2013                 [Page 5]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   Code Meaning
   ---- --------
   0    Query
   1    Initiate
   2    Refresh
   3    Release
   4    Accept
   5    Reject

   The remainder of the message consists of a sequence of Type-Length-
   Value (TLV) objects, which have the following format:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type             |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                             Value                             ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             TLV Object Format

   The Type field identifies the TLV Object; an IANA registry has been
   created to track the values of this field.  Types 0-127 are reserved
   for use by the SSCP itself, with the rest available for application-
   specific allocation.  The Length field specifies the length in octets
   of the Value field.

3.2.  TLV Objects

3.2.1.  Source Address

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 1         |            Length = 8         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Reserved           |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                            Address                            ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Source Address allows the initiator to inform the responder of
   its address when sending an Initiate or Query message.  The format of
   this object is identical to the Source Address TLV object described
   in [I-D.ietf-mpls-gach-adv].




Frost & Bryant           Expires April 15, 2013                 [Page 6]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


3.2.2.  Authentication

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 2         |            Length = 8         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Reserved             |            Key ID             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                    Authentication Data                        ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Authentication object allows the receiver of an SSCP message to
   verify the identity of the message source and the integrity of the
   message.  The format and processing semantics of this object are
   specified in [I-D.ietf-mpls-gach-adv].

3.2.3.  Session Type

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 3         |            Length = 4         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Session Type         |           Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Session Type is included in Initiate and Query messages and
   indicates the type of session that the initiator seeks to establish.
   An IANA registry has been created to track the values for the Session
   Type.

3.2.4.  Hold Time

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 4         |            Length = 4         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Reserved           |            Hold Time          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Hold Time object indicates the amount of time, in seconds, the
   responder should keep this session alive if a refresh message is not
   received.  When the hold timer expires, the responder discards all
   state associated with the session.  When a refresh message is
   received, the responder resets its hold timer to the Hold Time.




Frost & Bryant           Expires April 15, 2013                 [Page 7]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


3.2.5.  Error Information

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 5         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Error Code   |                Error Data                     ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Error Information object is included by the responder as part of
   a Reject message and identifies the reason for rejection in the form
   of an error code.  Some codes may carry additional error information,
   in which case this information is placed in the Error Data field.
   The Error Data field has zero length unless otherwise noted below.

   Error Code Meaning
   ---------- ------------------------
   0          Unspecified Error
   1          Protocol Error
   2          Resource Unavailable
   3          Unsupported Session Type
   4          Unsupported Parameter
   5          Authentication Failed
   6          Invalid Session

   Unspecified Error: An unspecified error has prevented the requested
   session from being accepted.  This code MUST NOT be used if a more
   specific code applies.

   Protocol Error: A protocol error was found when parsing the incoming
   message.

   Resource Unavailable: Node resources are not available to support the
   requested session.

   Unsupported Session Type: Support for the Session Type indicated in
   the incoming message is not available.

   Unsupported Parameter: Support for one or more of the requested
   session parameters is not available.  The Error Data field consists
   of a sequence of TLV objects for the bad parameters, copied from the
   original request.

   Authentication Failed: Authentication for the incoming message
   failed.  A response message carrying this code MAY be sent as an
   alternative to silently dropping the offending message.




Frost & Bryant           Expires April 15, 2013                 [Page 8]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   Invalid Session: The Responder Session Identifier in the incoming
   Refresh message is unknown or has been released.

3.3.  Session Setup

   The initiator begins by transmitting an Initiate message, i.e. a
   message with the Control Code set to Initiate.  The Initiate message
   MUST also contain a single instance each of the Session Type and Hold
   Time objects.

   Upon transmitting the first Initiate message, the initiator sets a
   retransmit timer.  The message is retransmitted until either a
   response is received or a locally-determined timeout occurs.  The
   retransmit period SHOULD be no shorter than three seconds.

   When the responder receives an Initiate message, it determines
   whether it can support the requested session.  If not, it sends a
   single Reject message to the initiator with the ISI copied from the
   Initiate message and with an Error Information object indicating the
   reason for rejection.  In the case of an Unsupported Parameter error,
   the responder also includes a set of TLV objects that describe the
   parameters it supports, called the "Supported Parameters" set.  This
   set includes the Hold Time object, which in this context indicates
   the longest hold time the responder supports for this session type.
   The other objects in the Supported Parameters set are specific to the
   session type.

   If the responder can support the requested session, it sets the hold
   timer for the session to the value specified by the Hold Time object
   and sends a single Accept message to the initiator.  The ISI of the
   Accept message is copied from the Initiate message, and the RSI is
   set at the responder's discretion.

   An alternative to the above procedure is for the initiator to begin
   by sending a Query rather than an Initiate message.  Upon receiving
   such a message, the responder responds with a Reject message that
   contains either an Error Information object or the Supported
   Parameters object set for this session type.  The ISI of the Reject
   message is copied from the Initiate message.

3.4.  Session Maintenance and Release

   Following the acceptance of a session, the responder maintains state
   for the session until the session's hold timer expires or a Release
   message for the session is received.  It MAY also terminate the
   session if an exceptional condition occurs; in this case it SHOULD
   send a Reject message to the initiator.




Frost & Bryant           Expires April 15, 2013                 [Page 9]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   In order to maintain the session over time, the initiator sends
   periodic Refresh messages containing the RSI signaled by the
   responder in its most recent Accept message for this session.  The
   responder responds to a Refresh with an Accept message containing its
   RSI and the ISI received in the Refresh.  The refresh interval SHOULD
   be less than one-third of the Hold Time for the session.

   When the initiator is finished with the session, it sends a Release
   message containing the RSI signaled by the responder in its most
   recent Accept message for this session.  Upon receiving a Release,
   the responder discards all state associated with the session.


4.  Test Session Parameters

   This document defines the following Session Type for use in
   establishing test traffic streams for packet loss and throughput
   measurement:

   Session Type                       Value
   ---------------------------------- ------
   Measurement Test Session           0x0001

   Test traffic streams are negotiated via the SSCP.  This negotiation
   determines the format and flow characteristics of the streams.

   The following subsections define the SSCP parameter objects for test
   sessions.

4.1.  Destination Test Identifier

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 128       |            Length = 4         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Destination Test Identifier (DTI)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The DTI is a 32-bit tag allocated by the session responder (test
   destination) that uniquely identifies this test stream at the
   destination.  The session initiator (test source) includes the DTI in
   test packets sent to the test destination, as well as in the Target
   Identifier field of LM messages measuring this test stream.

   [Editor's note: An extension is proposed to the RFC 6374 LM message
   format whereby a block of 20 reserved bits is allocated for a "Target
   Identifier" field that explicitly specifies the measurement target of



Frost & Bryant           Expires April 15, 2013                [Page 10]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   this LM message, via a responder-allocated identifier such as the
   DTI.]

   Because the Target Identifier field in the LM message format is only
   20 bits long, the following restriction is placed on the DTI: If a
   test stream is or may be the target of an LM session, then the DTI
   value MUST be confined to the low-order 20 bits of the 32-bit field,
   and the high-order 12 bits of this field MUST be set to zero.
   Furthermore, the implementation MUST assume by default that this
   restriction is in force.

   In some cases the DTI field carries an MPLS label [RFC3032].  When
   this is the case, the label is encoded in the low-order 20 bits of
   the field; the high-order 12 bits are set to zero.

4.2.  Source Test Identifier

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 129       |            Length = 4         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Source Test Identifier (STI)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The STI is a 32-bit tag allocated by the session initiator (test
   source) that uniquely identifies this test stream at the source.  For
   bidirectional test streams, the STI replaces the DTI in the body of
   test messages reflected by the destination back to the source.

   In some cases the STI field carries an MPLS label.  When this is the
   case, the label is encoded in the low-order 20 bits of the field; the
   high-order 12 bits are set to zero.

4.3.  Packet Format

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 130       |            Length = 4         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Format Type  |                  Reserved                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Packet Format object identifies the format of test packets in
   this test stream.  Possible values are:





Frost & Bryant           Expires April 15, 2013                [Page 11]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   Type Meaning
   ---- ----------------------------------
   0    Generic Associated Channel (G-ACh)
   1    MPLS Label

   The G-ACh format indicates that test messages are sent over the G-ACh
   using the Channel Type allocated by IANA for test messages.  In this
   case, test messages have the following format (after the Associated
   Channel Header):

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Test Identifier                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                            Payload                            ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this format, the Test Identifier is set to the DTI in test
   messages transmitted by the test source to the test destination.  In
   bidirectional test streams, the destination sets the Test Identifier
   to the STI before reflecting test messages it receives back to the
   source.  The test message payload is set at the discretion of the
   test source.  Support for the G-ACh format is REQUIRED.

   The MPLS Label format indicates that test messages are sent as MPLS
   packets with a specific label at the bottom of the stack.  The label
   values allocated by the test source and test destination are signaled
   via the STI and DTI objects respectively (the former only for
   bidirectional test streams).  In this case the label serves as the
   test identifier; the body of the packet, i.e. the portion that
   follows the MPLS label stack, is considered the payload and set at
   the discretion of the test source.

4.4.  Path Type

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 131       |            Length = 4         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Path Type   |                  Reserved                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Path Type object indicates whether the test stream is
   unidirectional or bidirectional.  In a unidirectional stream, test
   packets are sent from the test source to the test destination and are
   then discarded.  In a bidirectional stream, test packets are sent



Frost & Bryant           Expires April 15, 2013                [Page 12]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   from the source to the destination and reflected back to the source.
   Support for unidirectional sessions is REQUIRED.

   Type Meaning
   ---- --------------
   0    Unidirectional
   1    Bidirectional

4.5.  Payload Size Range

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 132       |            Length = 4         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Min Size           |            Max Size           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Payload Size Range object indicates the minimum and maximum sizes
   of test payloads that may be sent in this session.  The sizes are
   specified in octets, and refer to the payload portion of test
   packets.  For example, for the "Generic Associated Channel" test
   packet format the payload begins after the "Test Identifier" field,
   and for the "MPLS Label" format it begins after the label stack.

4.6.  Maximum Transmission Rate

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Type = 133       |            Length = 4         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Maximum Transmission Rate                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Maximum Transmission Rate object indicates the maximum number of
   test packets per second that may be sent in this session.


5.  Test Session Control

   Test session control takes place according to the procedures in
   Section 3.3 and Section 3.4.  In addition to the Session Type and
   Hold Time objects, the initiator MUST also include in Initiate
   messages a single instance each of the Payload Size Range and Maximum
   Transmission Rate objects.  If the Packet Format object is omitted,
   then the "Generic Associated Channel" packet format is implied.  If
   the Path Type object is omitted, then a unidirectional test stream is



Frost & Bryant           Expires April 15, 2013                [Page 13]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   implied.  If a bidirectional test stream is requested via the Path
   Type, then a Source Test Identifier object MUST also be included.

   If the responder can support the requested stream, it includes a
   Destination Test Identifier object in its Accept message.

   For purposes of Unsupported Parameter errors and responses to Query
   messages, the Supported Parameters set includes the Packet Format,
   Path Type, Payload Size Range, and Maximum Transmission Rate objects.


6.  Security Considerations

   This document describes a simple control protocol that allows two
   devices to negotiate a session via the MPLS Generic Associated
   Channel.  The most important security considerations are those that
   apply to securing MPLS connectivity in general; these are documented
   in [RFC5920].  The control protocol described in this document
   exchanges session data in cleartext, as this information is no more
   sensitive than that contained in other protocol messages that are
   commonly sent in cleartext.  The main security considerations
   specific to this protocol are those concerning the verification of
   message authenticity and integrity, and possible denial of service.

   An authentication mechanism based on cryptographic message hashing is
   included in the protocol, enabling receivers to verify that protocol
   messages were generated by a trusted source and were not corrupted or
   otherwise modified in transit.  This mechanism also affords
   protection against denial-of-service attempts made by unauthorized
   devices.  Receivers, in addition, SHOULD employ sensible rate-
   limiting policies to guard against the possibility of intentional or
   accidental denial-of-service by authorized devices.  For example,
   implementations SHOULD anticipate the effects of receiving a large
   number of Initiate or Query messages within a short period of time,
   and take appropriate precautions to avoid resource exhaustion in such
   scenarios.


7.  IANA Considerations

   This document makes the following requests of IANA:

   o  Allocation of Associated Channel Types

   o  Creation of MPLS Simple Session Control Protocol TLV Registry

   o  Creation of MPLS Simple Session Control Protocol Session Type
      Registry



Frost & Bryant           Expires April 15, 2013                [Page 14]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


7.1.  Allocation of Associated Channel Types

   IANA is requested to allocate an entry in the Pseudowire Associated
   Channel Types registry [RFC5586] for the MPLS Simple Session Control
   Protocol, as follows:

   Value Description                          TLV Follows Reference
   ----- ------------------------------------ ----------- ------------
   (TBD) MPLS Simple Session Control Protocol No          (this draft)

   IANA is also requested to allocate an entry in the same registry for
   MPLS test messages, as follows:

   Value Description       TLV Follows Reference
   ----- ----------------- ----------- ------------
   (TBD) MPLS Test Message No          (this draft)

7.2.  Creation of MPLS Simple Session Control Protocol TLV Registry

   IANA is requested to create a new registry, "MPLS Simple Session
   Control Protocol TLVs", with fields and initial allocations as
   follows:

   Type Application Name        Description                 Reference
   ---- ----------------------- --------------------------- ------------
   1    Simple Session Control  Source Address              (this draft)
        Protocol
   2    Simple Session Control  Authentication              (this draft)
        Protocol
   3    Simple Session Control  Session Type                (this draft)
        Protocol
   4    Simple Session Control  Hold Time                   (this draft)
        Protocol
   5    Simple Session Control  Error Information           (this draft)
        Protocol
   128  Test Session Control    Destination Test Identifier (this draft)
   129  Test Session Control    Source Test Identifier      (this draft)
   130  Test Session Control    Packet Format               (this draft)
   131  Test Session Control    Path Type                   (this draft)
   132  Test Session Control    Payload Size Range          (this draft)
   133  Test Session Control    Maximum Transmission Rate   (this draft)

7.3.  Creation of MPLS Simple Session Control Protocol Session Type
      Registry

   IANA is requested to create a new registry, "MPLS Simple Session
   Control Protocol Session Types", with fields and initial allocations
   as follows:



Frost & Bryant           Expires April 15, 2013                [Page 15]

Internet-Draft       MPLS G-ACh Test Session Control        October 2012


   Session Type Description          Reference
   ------------ -------------------- ------------
   1            Test Session Control (this draft)


8.  Normative References

   [I-D.ietf-mpls-gach-adv]
              Frost, D., Bryant, S., and M. Bocci, "MPLS Generic
              Associated Channel (G-ACh) Advertisement Protocol",
              draft-ietf-mpls-gach-adv-02 (work in progress), May 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.


Authors' Addresses

   Dan Frost
   Cisco Systems

   Email: danfrost@cisco.com


   Stewart Bryant
   Cisco Systems

   Email: stbryant@cisco.com










Frost & Bryant           Expires April 15, 2013                [Page 16]