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]