idnits 2.17.00 (12 Aug 2021) /tmp/idnits31090/draft-frost-mpls-test-session-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2012) is 3501 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-mpls-gach-adv has been published as RFC 7212 ** Downref: Normative reference to an Informational RFC: RFC 5920 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS D. Frost 3 Internet-Draft S. Bryant 4 Intended status: Standards Track Cisco Systems 5 Expires: April 15, 2013 October 12, 2012 7 MPLS Generic Associated Channel (G-ACh) Test Session Control 8 draft-frost-mpls-test-session-00 10 Abstract 12 RFC 6374 defines procedures for packet loss and throughput 13 measurement in MPLS networks. Some forms of measurement rely on the 14 existence of a stream of test messages that flows between measurement 15 points, from which the loss and throughput characteristics of the 16 underlying data channel are inferred. This document presents 17 procedures for the establishment and maintenance of such test 18 sessions. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 15, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Simple Session Control Protocol . . . . . . . . . . . . . . . 4 59 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Session Setup . . . . . . . . . . . . . . . . . . . . . . 9 62 3.4. Session Maintenance and Release . . . . . . . . . . . . . 9 63 4. Test Session Parameters . . . . . . . . . . . . . . . . . . . 10 64 4.1. Destination Test Identifier . . . . . . . . . . . . . . . 10 65 4.2. Source Test Identifier . . . . . . . . . . . . . . . . . . 11 66 4.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . 11 67 4.4. Path Type . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.5. Payload Size Range . . . . . . . . . . . . . . . . . . . . 13 69 4.6. Maximum Transmission Rate . . . . . . . . . . . . . . . . 13 70 5. Test Session Control . . . . . . . . . . . . . . . . . . . . . 13 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 7.1. Allocation of Associated Channel Types . . . . . . . . . . 15 74 7.2. Creation of MPLS Simple Session Control Protocol TLV 75 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 7.3. Creation of MPLS Simple Session Control Protocol 77 Session Type Registry . . . . . . . . . . . . . . . . . . 15 78 8. Normative References . . . . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Procedures and protocol messages for packet loss, delay, and 84 throughput measurement in MPLS networks are documented in [RFC6374]. 85 Packet loss measurement, in that document, is classified as either 86 direct or inferred: direct measurement is based on comparing transmit 87 and receive counters for all data-plane traffic flowing over the 88 channel, while inferred measurement is based on comparing the 89 equivalent counters for a distinct stream of test traffic. 90 Similarly, out-of-service throughput measurement entails validating 91 the data-plane capacity of a channel by generating a stream of test 92 traffic at a rate that meets or exceeds the expected capacity. 94 The Loss Measurement (LM) protocol defined in RFC 6374 relies on the 95 existence of a test traffic stream when used to conduct inferred LM 96 or out-of-service throughput measurement. This document defines 97 procedures for the setup and control of such test streams via the 98 MPLS Generic Associated Channel (G-ACh) [RFC5586]. 100 1.1. Terminology 102 Term Definition 103 ----- ------------------------------- 104 G-ACh Generic Associated Channel 105 LM Loss Measurement 106 SSCP Simple Session Control Protocol 107 TLV Type-Length-Value 109 1.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Overview 117 The objective is for a device acting as an LM querier to establish a 118 test traffic stream to the LM responder in advance of initiating the 119 LM session; this stream can then serve as the target of the LM 120 operation, persisting until the operation is finished. Test session 121 setup and maintenance proceeds according to the following process: 123 1. The querier determines the desired parameters for the test 124 session, encodes them in a setup message as specified later in 125 this document, and sends it to the responder. This message is 126 transmitted periodically until either a response is forthcoming 127 or a timeout occurs. 129 2. The responder, upon receiving the test session parameters, either 130 accepts or rejects them. In either case, it formulates a 131 response and sends it to the querier. The response indicates 132 whether the session is accepted or rejected and, in the latter 133 case, parameters that the responder considers acceptable. If the 134 session was accepted, it is now considered "alive" at the 135 responder, which maintains state for it until it times out or is 136 explicitly released. 138 3. The querier, upon receiving the responder's message, knows 139 whether the test session is now active. If not, it can retry the 140 attempt using parameters the responder has indicated are 141 acceptable. If so, it now does three things: it begins sending 142 test traffic; it periodically sends a message refreshing/ 143 verifying the test session state; and it initiates an LM session 144 that targets this test session. 146 4. The querier, when finished with the measurement operation, 147 terminates the LM session, ceases sending test traffic, and sends 148 an advisory message to the responder that the test session has 149 ended. 151 In the remainder of this document the term "querier" is replaced by 152 "initiator" in the context of test session control. 154 3. Simple Session Control Protocol 156 This document defines a new G-ACh protocol and associated Channel 157 Type: 159 Protocol Channel Type 160 ---------------------------------- ------------ 161 Simple Session Control Protocol 0xXXXX 163 For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV 164 Header defined in [RFC5586]. 166 The Simple Session Control Protocol (SSCP) is a minimal "skeleton 167 protocol" for the setup and control of point-to-point "sessions" over 168 the G-ACh, where a session is defined abstractly as an initial 169 agreement of application-specific parameters between the initiator 170 and responder, followed by some form of state that is maintained 171 between the two endpoints until either a timeout occurs or the 172 session is explicitly released. 174 The only SSCP application discussed in this document is that of 175 measurement test stream control. However, the SSCP has been defined 176 in a general form with the view that it may have other future 177 applications. 179 3.1. Message Format 181 The following figure shows the format of an SSCP message, which 182 follows the Associated Channel Header (ACH): 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |Version| Resv | Control Code | Message Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Initiator Session Identifier (ISI) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Responder Session Identifier (RSI) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 ~ TLV Block ~ 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 SSCP Message Format 198 Fields in this document shown as Reserved or Resv are reserved for 199 future specification and MUST be set to zero. All integer values for 200 fields defined in this document SHALL be encoded in network byte 201 order. 203 In this format, the Version field indicates the protocol version and 204 is currently set to 0. The Message Length field indicates the size 205 in octets of this message (i.e. of the portion of the packet that 206 follows the Associated Channel Header). The Initiator Session 207 Identifier (ISI) and Responder Session Identifier (RSI) fields 208 identify the specific session to which this message belongs, via 209 locally-significant tags allocated by the initiator and the responder 210 respectively. 212 The Control Code indicates whether this message is querying, 213 initiating, refreshing, releasing, accepting, or rejecting a session. 214 The first four values are used by the initiator, the last two by the 215 responder: 217 Code Meaning 218 ---- -------- 219 0 Query 220 1 Initiate 221 2 Refresh 222 3 Release 223 4 Accept 224 5 Reject 226 The remainder of the message consists of a sequence of Type-Length- 227 Value (TLV) objects, which have the following format: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 ~ Value ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 TLV Object Format 239 The Type field identifies the TLV Object; an IANA registry has been 240 created to track the values of this field. Types 0-127 are reserved 241 for use by the SSCP itself, with the rest available for application- 242 specific allocation. The Length field specifies the length in octets 243 of the Value field. 245 3.2. TLV Objects 247 3.2.1. Source Address 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type = 1 | Length = 8 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Reserved | Address Family | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 ~ Address ~ 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 The Source Address allows the initiator to inform the responder of 260 its address when sending an Initiate or Query message. The format of 261 this object is identical to the Source Address TLV object described 262 in [I-D.ietf-mpls-gach-adv]. 264 3.2.2. Authentication 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type = 2 | Length = 8 | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Reserved | Key ID | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 ~ Authentication Data ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 The Authentication object allows the receiver of an SSCP message to 277 verify the identity of the message source and the integrity of the 278 message. The format and processing semantics of this object are 279 specified in [I-D.ietf-mpls-gach-adv]. 281 3.2.3. Session Type 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type = 3 | Length = 4 | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Session Type | Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 The Session Type is included in Initiate and Query messages and 292 indicates the type of session that the initiator seeks to establish. 293 An IANA registry has been created to track the values for the Session 294 Type. 296 3.2.4. Hold Time 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type = 4 | Length = 4 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Reserved | Hold Time | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 The Hold Time object indicates the amount of time, in seconds, the 307 responder should keep this session alive if a refresh message is not 308 received. When the hold timer expires, the responder discards all 309 state associated with the session. When a refresh message is 310 received, the responder resets its hold timer to the Hold Time. 312 3.2.5. Error Information 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type = 5 | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Error Code | Error Data ~ 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 The Error Information object is included by the responder as part of 323 a Reject message and identifies the reason for rejection in the form 324 of an error code. Some codes may carry additional error information, 325 in which case this information is placed in the Error Data field. 326 The Error Data field has zero length unless otherwise noted below. 328 Error Code Meaning 329 ---------- ------------------------ 330 0 Unspecified Error 331 1 Protocol Error 332 2 Resource Unavailable 333 3 Unsupported Session Type 334 4 Unsupported Parameter 335 5 Authentication Failed 336 6 Invalid Session 338 Unspecified Error: An unspecified error has prevented the requested 339 session from being accepted. This code MUST NOT be used if a more 340 specific code applies. 342 Protocol Error: A protocol error was found when parsing the incoming 343 message. 345 Resource Unavailable: Node resources are not available to support the 346 requested session. 348 Unsupported Session Type: Support for the Session Type indicated in 349 the incoming message is not available. 351 Unsupported Parameter: Support for one or more of the requested 352 session parameters is not available. The Error Data field consists 353 of a sequence of TLV objects for the bad parameters, copied from the 354 original request. 356 Authentication Failed: Authentication for the incoming message 357 failed. A response message carrying this code MAY be sent as an 358 alternative to silently dropping the offending message. 360 Invalid Session: The Responder Session Identifier in the incoming 361 Refresh message is unknown or has been released. 363 3.3. Session Setup 365 The initiator begins by transmitting an Initiate message, i.e. a 366 message with the Control Code set to Initiate. The Initiate message 367 MUST also contain a single instance each of the Session Type and Hold 368 Time objects. 370 Upon transmitting the first Initiate message, the initiator sets a 371 retransmit timer. The message is retransmitted until either a 372 response is received or a locally-determined timeout occurs. The 373 retransmit period SHOULD be no shorter than three seconds. 375 When the responder receives an Initiate message, it determines 376 whether it can support the requested session. If not, it sends a 377 single Reject message to the initiator with the ISI copied from the 378 Initiate message and with an Error Information object indicating the 379 reason for rejection. In the case of an Unsupported Parameter error, 380 the responder also includes a set of TLV objects that describe the 381 parameters it supports, called the "Supported Parameters" set. This 382 set includes the Hold Time object, which in this context indicates 383 the longest hold time the responder supports for this session type. 384 The other objects in the Supported Parameters set are specific to the 385 session type. 387 If the responder can support the requested session, it sets the hold 388 timer for the session to the value specified by the Hold Time object 389 and sends a single Accept message to the initiator. The ISI of the 390 Accept message is copied from the Initiate message, and the RSI is 391 set at the responder's discretion. 393 An alternative to the above procedure is for the initiator to begin 394 by sending a Query rather than an Initiate message. Upon receiving 395 such a message, the responder responds with a Reject message that 396 contains either an Error Information object or the Supported 397 Parameters object set for this session type. The ISI of the Reject 398 message is copied from the Initiate message. 400 3.4. Session Maintenance and Release 402 Following the acceptance of a session, the responder maintains state 403 for the session until the session's hold timer expires or a Release 404 message for the session is received. It MAY also terminate the 405 session if an exceptional condition occurs; in this case it SHOULD 406 send a Reject message to the initiator. 408 In order to maintain the session over time, the initiator sends 409 periodic Refresh messages containing the RSI signaled by the 410 responder in its most recent Accept message for this session. The 411 responder responds to a Refresh with an Accept message containing its 412 RSI and the ISI received in the Refresh. The refresh interval SHOULD 413 be less than one-third of the Hold Time for the session. 415 When the initiator is finished with the session, it sends a Release 416 message containing the RSI signaled by the responder in its most 417 recent Accept message for this session. Upon receiving a Release, 418 the responder discards all state associated with the session. 420 4. Test Session Parameters 422 This document defines the following Session Type for use in 423 establishing test traffic streams for packet loss and throughput 424 measurement: 426 Session Type Value 427 ---------------------------------- ------ 428 Measurement Test Session 0x0001 430 Test traffic streams are negotiated via the SSCP. This negotiation 431 determines the format and flow characteristics of the streams. 433 The following subsections define the SSCP parameter objects for test 434 sessions. 436 4.1. Destination Test Identifier 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type = 128 | Length = 4 | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Destination Test Identifier (DTI) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 The DTI is a 32-bit tag allocated by the session responder (test 447 destination) that uniquely identifies this test stream at the 448 destination. The session initiator (test source) includes the DTI in 449 test packets sent to the test destination, as well as in the Target 450 Identifier field of LM messages measuring this test stream. 452 [Editor's note: An extension is proposed to the RFC 6374 LM message 453 format whereby a block of 20 reserved bits is allocated for a "Target 454 Identifier" field that explicitly specifies the measurement target of 455 this LM message, via a responder-allocated identifier such as the 456 DTI.] 458 Because the Target Identifier field in the LM message format is only 459 20 bits long, the following restriction is placed on the DTI: If a 460 test stream is or may be the target of an LM session, then the DTI 461 value MUST be confined to the low-order 20 bits of the 32-bit field, 462 and the high-order 12 bits of this field MUST be set to zero. 463 Furthermore, the implementation MUST assume by default that this 464 restriction is in force. 466 In some cases the DTI field carries an MPLS label [RFC3032]. When 467 this is the case, the label is encoded in the low-order 20 bits of 468 the field; the high-order 12 bits are set to zero. 470 4.2. Source Test Identifier 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type = 129 | Length = 4 | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Source Test Identifier (STI) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 The STI is a 32-bit tag allocated by the session initiator (test 481 source) that uniquely identifies this test stream at the source. For 482 bidirectional test streams, the STI replaces the DTI in the body of 483 test messages reflected by the destination back to the source. 485 In some cases the STI field carries an MPLS label. When this is the 486 case, the label is encoded in the low-order 20 bits of the field; the 487 high-order 12 bits are set to zero. 489 4.3. Packet Format 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type = 130 | Length = 4 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Format Type | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 The Packet Format object identifies the format of test packets in 500 this test stream. Possible values are: 502 Type Meaning 503 ---- ---------------------------------- 504 0 Generic Associated Channel (G-ACh) 505 1 MPLS Label 507 The G-ACh format indicates that test messages are sent over the G-ACh 508 using the Channel Type allocated by IANA for test messages. In this 509 case, test messages have the following format (after the Associated 510 Channel Header): 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Test Identifier | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 ~ Payload ~ 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 In this format, the Test Identifier is set to the DTI in test 521 messages transmitted by the test source to the test destination. In 522 bidirectional test streams, the destination sets the Test Identifier 523 to the STI before reflecting test messages it receives back to the 524 source. The test message payload is set at the discretion of the 525 test source. Support for the G-ACh format is REQUIRED. 527 The MPLS Label format indicates that test messages are sent as MPLS 528 packets with a specific label at the bottom of the stack. The label 529 values allocated by the test source and test destination are signaled 530 via the STI and DTI objects respectively (the former only for 531 bidirectional test streams). In this case the label serves as the 532 test identifier; the body of the packet, i.e. the portion that 533 follows the MPLS label stack, is considered the payload and set at 534 the discretion of the test source. 536 4.4. Path Type 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type = 131 | Length = 4 | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Path Type | Reserved | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 The Path Type object indicates whether the test stream is 547 unidirectional or bidirectional. In a unidirectional stream, test 548 packets are sent from the test source to the test destination and are 549 then discarded. In a bidirectional stream, test packets are sent 550 from the source to the destination and reflected back to the source. 551 Support for unidirectional sessions is REQUIRED. 553 Type Meaning 554 ---- -------------- 555 0 Unidirectional 556 1 Bidirectional 558 4.5. Payload Size Range 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type = 132 | Length = 4 | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Min Size | Max Size | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 The Payload Size Range object indicates the minimum and maximum sizes 569 of test payloads that may be sent in this session. The sizes are 570 specified in octets, and refer to the payload portion of test 571 packets. For example, for the "Generic Associated Channel" test 572 packet format the payload begins after the "Test Identifier" field, 573 and for the "MPLS Label" format it begins after the label stack. 575 4.6. Maximum Transmission Rate 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type = 133 | Length = 4 | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Maximum Transmission Rate | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 The Maximum Transmission Rate object indicates the maximum number of 586 test packets per second that may be sent in this session. 588 5. Test Session Control 590 Test session control takes place according to the procedures in 591 Section 3.3 and Section 3.4. In addition to the Session Type and 592 Hold Time objects, the initiator MUST also include in Initiate 593 messages a single instance each of the Payload Size Range and Maximum 594 Transmission Rate objects. If the Packet Format object is omitted, 595 then the "Generic Associated Channel" packet format is implied. If 596 the Path Type object is omitted, then a unidirectional test stream is 597 implied. If a bidirectional test stream is requested via the Path 598 Type, then a Source Test Identifier object MUST also be included. 600 If the responder can support the requested stream, it includes a 601 Destination Test Identifier object in its Accept message. 603 For purposes of Unsupported Parameter errors and responses to Query 604 messages, the Supported Parameters set includes the Packet Format, 605 Path Type, Payload Size Range, and Maximum Transmission Rate objects. 607 6. Security Considerations 609 This document describes a simple control protocol that allows two 610 devices to negotiate a session via the MPLS Generic Associated 611 Channel. The most important security considerations are those that 612 apply to securing MPLS connectivity in general; these are documented 613 in [RFC5920]. The control protocol described in this document 614 exchanges session data in cleartext, as this information is no more 615 sensitive than that contained in other protocol messages that are 616 commonly sent in cleartext. The main security considerations 617 specific to this protocol are those concerning the verification of 618 message authenticity and integrity, and possible denial of service. 620 An authentication mechanism based on cryptographic message hashing is 621 included in the protocol, enabling receivers to verify that protocol 622 messages were generated by a trusted source and were not corrupted or 623 otherwise modified in transit. This mechanism also affords 624 protection against denial-of-service attempts made by unauthorized 625 devices. Receivers, in addition, SHOULD employ sensible rate- 626 limiting policies to guard against the possibility of intentional or 627 accidental denial-of-service by authorized devices. For example, 628 implementations SHOULD anticipate the effects of receiving a large 629 number of Initiate or Query messages within a short period of time, 630 and take appropriate precautions to avoid resource exhaustion in such 631 scenarios. 633 7. IANA Considerations 635 This document makes the following requests of IANA: 637 o Allocation of Associated Channel Types 639 o Creation of MPLS Simple Session Control Protocol TLV Registry 641 o Creation of MPLS Simple Session Control Protocol Session Type 642 Registry 644 7.1. Allocation of Associated Channel Types 646 IANA is requested to allocate an entry in the Pseudowire Associated 647 Channel Types registry [RFC5586] for the MPLS Simple Session Control 648 Protocol, as follows: 650 Value Description TLV Follows Reference 651 ----- ------------------------------------ ----------- ------------ 652 (TBD) MPLS Simple Session Control Protocol No (this draft) 654 IANA is also requested to allocate an entry in the same registry for 655 MPLS test messages, as follows: 657 Value Description TLV Follows Reference 658 ----- ----------------- ----------- ------------ 659 (TBD) MPLS Test Message No (this draft) 661 7.2. Creation of MPLS Simple Session Control Protocol TLV Registry 663 IANA is requested to create a new registry, "MPLS Simple Session 664 Control Protocol TLVs", with fields and initial allocations as 665 follows: 667 Type Application Name Description Reference 668 ---- ----------------------- --------------------------- ------------ 669 1 Simple Session Control Source Address (this draft) 670 Protocol 671 2 Simple Session Control Authentication (this draft) 672 Protocol 673 3 Simple Session Control Session Type (this draft) 674 Protocol 675 4 Simple Session Control Hold Time (this draft) 676 Protocol 677 5 Simple Session Control Error Information (this draft) 678 Protocol 679 128 Test Session Control Destination Test Identifier (this draft) 680 129 Test Session Control Source Test Identifier (this draft) 681 130 Test Session Control Packet Format (this draft) 682 131 Test Session Control Path Type (this draft) 683 132 Test Session Control Payload Size Range (this draft) 684 133 Test Session Control Maximum Transmission Rate (this draft) 686 7.3. Creation of MPLS Simple Session Control Protocol Session Type 687 Registry 689 IANA is requested to create a new registry, "MPLS Simple Session 690 Control Protocol Session Types", with fields and initial allocations 691 as follows: 693 Session Type Description Reference 694 ------------ -------------------- ------------ 695 1 Test Session Control (this draft) 697 8. Normative References 699 [I-D.ietf-mpls-gach-adv] 700 Frost, D., Bryant, S., and M. Bocci, "MPLS Generic 701 Associated Channel (G-ACh) Advertisement Protocol", 702 draft-ietf-mpls-gach-adv-02 (work in progress), May 2012. 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, March 1997. 707 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 708 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 709 Encoding", RFC 3032, January 2001. 711 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 712 Associated Channel", RFC 5586, June 2009. 714 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 715 Networks", RFC 5920, July 2010. 717 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 718 Measurement for MPLS Networks", RFC 6374, September 2011. 720 Authors' Addresses 722 Dan Frost 723 Cisco Systems 725 Email: danfrost@cisco.com 727 Stewart Bryant 728 Cisco Systems 730 Email: stbryant@cisco.com