idnits 2.17.1 draft-ietf-mpls-gach-adv-08.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (June 07, 2013) is 3966 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: A later version (-10) exists of draft-ietf-karp-crypto-key-table-07 ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-03) exists of draft-ietf-mpls-retire-ach-tlv-00 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-tp-ethernet-addressing-07 Summary: 1 error (**), 0 flaws (~~), 5 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: December 09, 2013 M. Bocci 6 Alcatel-Lucent 7 June 07, 2013 9 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol 10 draft-ietf-mpls-gach-adv-08 12 Abstract 14 The MPLS Generic Associated Channel (G-ACh) provides an auxiliary 15 logical data channel associated with a Label Switched Path (LSP), a 16 pseudowire, or a section (link) over which a variety of protocols may 17 flow. These protocols are commonly used to provide Operations, 18 Administration, and Maintenance (OAM) mechanisms associated with the 19 primary data channel. This document specifies simple procedures by 20 which an endpoint of an LSP, pseudowire, or section may inform the 21 other endpoints of its capabilities and configuration parameters, or 22 other application-specific information. This information may then be 23 used by the receiver to validate or adjust its local configuration, 24 and by the network operator for diagnostic purposes. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 09, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. GAP Message Format . . . . . . . . . . . . . . . . . . . 7 67 3.2. Applications Data Block . . . . . . . . . . . . . . . . . 8 68 3.3. TLV Object Format . . . . . . . . . . . . . . . . . . . . 9 69 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 9 70 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . 10 71 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 11 72 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 12 73 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . 12 74 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . 13 75 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. Message Transmission . . . . . . . . . . . . . . . . . . 13 77 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 14 78 6. Message Authentication . . . . . . . . . . . . . . . . . . . 15 79 6.1. Authentication Key Identifiers . . . . . . . . . . . . . 15 80 6.2. Authentication Process . . . . . . . . . . . . . . . . . 16 81 6.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 17 82 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 18 83 8. Managability Considerations . . . . . . . . . . . . . . . . . 18 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 10.1. Associated Channel Type Allocation . . . . . . . . . . . 19 87 10.2. Allocation of Address Family Numbers . . . . . . . . . . 19 88 10.3. Creation of G-ACh Advertisement Protocol Application 89 Registry . . . . . . . . . . . . . . . . . . . . . . . . 19 90 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . 20 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 12.2. Informative References . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 The MPLS Generic Associated Channel (G-ACh) is defined and described 100 in [RFC5586]. It provides an auxiliary logical data channel over 101 which a variety of protocols may flow. Each such data channel is 102 associated with an MPLS Label Switched Path (LSP), a pseudowire, or a 103 section (link). An important use of the G-ACh and the protocols it 104 supports is to provide Operations, Administration, and Maintenance 105 (OAM) [RFC6291] capabilities for the associated LSP, pseudowire, or 106 section. Examples of such capabilities include Pseudowire Virtual 107 Circuit Connectivity Verification (VCCV) [RFC5085], Bidirectional 108 Forwarding Detection (BFD) for MPLS [RFC5884], and MPLS packet loss, 109 delay, and throughput measurement [RFC6374], as well as OAM functions 110 developed for the MPLS Transport Profile (MPLS-TP) [RFC5921]. 112 This document specifies procedures for an MPLS Label Switching Router 113 (LSR) to advertise its capabilities and configuration parameters, or 114 other application-specific information, to its peers over LSPs, 115 pseudowires, and sections. Receivers can then make use of this 116 information to validate or adjust their own configurations, and 117 network operators can make use of it to diagnose faults and 118 configuration inconsistencies between endpoints. Note in this 119 document, an "application" refers an application of G-ACh, and should 120 not be confused with an end-user application. 122 The main principle guiding the design of the MPLS G-ACh Advertisement 123 Protocol (GAP) is simplicity. The protocol provides a one-way method 124 of distributing information about the sender. How this information 125 is used by a given receiver is a local matter. The data elements 126 distributed by the GAP are application-specific and, except for those 127 associated with the GAP itself, are outside the scope of this 128 document. An IANA registry is created to allow GAP applications to 129 be defined as needed. 131 Note that assigning application identifiers and associated parameters 132 for protocols other than the GAP itself is out of scope for this 133 document, and will need to be done in subsequent documents, using the 134 IANA considerations specified here. 136 1.1. Motivation 138 It is frequently useful in a network for a node to have general 139 information about its adjacent nodes, i.e., those nodes to which it 140 has links. At a minimum this allows a human operator or management 141 application with access to the node to determine which adjacent nodes 142 this node can see, which is helpful when troubleshooting connectivity 143 problems. A typical example of an "adjacency awareness protocol" is 144 the Link Layer Discovery Protocol [LLDP], which can provide various 145 pieces of information about adjacent nodes in Ethernet networks, such 146 as system name, basic functional capabilities, link speed/duplex 147 settings, and maximum supported frame size. Such data is useful both 148 for human diagnostics and for automated detection of configuration 149 inconsistencies. 151 In MPLS networks, the G-ACh provides a convenient link-layer-agnostic 152 means for communication between LSRs that are adjacent at the link 153 layer. The G-ACh advertisement protocol presented in this document 154 thus allows LSRs to exchange information of a similar sort to that 155 supported by LLDP for Ethernet links. The GAP, however, does not 156 depend on the specific link-layer protocol in use, and can be used to 157 advertise information on behalf of any MPLS application. 159 In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] 160 that do not also support IP, the normal protocols used to determine 161 the Ethernet address of an adjacent MPLS node, such as the Address 162 Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery 163 [RFC4861], are not available. One possible use of the G-ACh 164 advertisement protocol is to discover the Ethernet media access 165 control addresses of MPLS-TP nodes lacking IP capability 166 [I-D.ietf-mpls-tp-ethernet-addressing]. However, where it is 167 anticipated that the only data that needs to be exchanged between 168 LSRs over an Ethernet link are their Ethernet addresses, then the 169 operator may instead choose to use LLDP for that purpose. 171 The applicability of the G-ACh advertisement protocol is not limited 172 to link-layer adjacency, either in terms of message distribution or 173 message content. The G-ACh exists for any MPLS LSP or pseudowire, so 174 GAP messages can be exchanged with remote LSP or pseudowire 175 endpoints. The content of GAP messages is extensible in a simple 176 manner, and can include any kind of information that might be useful 177 to MPLS LSRs connected by links, LSPs, or pseudowires. For example, 178 in networks that rely on the G-ACh for OAM functions, GAP messages 179 might be used to inform adjacent LSRs of a node's OAM capabilities 180 and configuration parameters. 182 1.2. Terminology 184 Term Definition 185 ----- ------------------------------------------- 186 G-ACh Generic Associated Channel 187 GAL G-ACh Label 188 GAP G-ACh Advertisement Protocol 189 LSP Label Switched Path 190 OAM Operations, Administration, and Maintenance 192 1.3. Requirements Language 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 2. Overview 200 The G-ACh Advertisement Protocol has a simple one-way mode of 201 operation: a device configured to send information for a particular 202 data channel (MPLS LSP, pseudowire, or section) transmits GAP 203 messages over the G-ACh associated with the data channel. The 204 payload of a GAP message is a collection of Type-Length-Value (TLV) 205 objects, organized on a per-application basis. An IANA registry is 206 created to identify specific applications. Application TLV objects 207 primarily contain static data that the receiver is meant to retain 208 for a period of time, but may also represent metadata or special 209 processing instructions. 211 Each GAP message can contain data for several applications. A sender 212 may transmit a targeted update that refreshes the data for a subset 213 of applications without affecting the data of other applications sent 214 on a previous message. GAP messages are processed in the order in 215 which they are received. 217 For example, a GAP message might be sent containing the following 218 data: 220 Application A: A-TLV4, A-TLV15, A-TLV9 222 Application B: B-TLV1, B-TLV3 224 Application C: C-TLV6, 226 where the TLVx refers to an example GAP TLV. 228 A second message might then be sent containing: 230 Application B: B-TLV7, B-TLV3 232 Upon receiving the second message, the receiver retains B-TLV1 from 233 the first message and adds B-TLV7 to its B-database. How it handles 234 the new B-TLV3 depends on the rules B has specified for this object 235 type; this object could replace the old one or be combined with it in 236 some way. The second message has no effect on the databases 237 maintained by the receiver for Applications A and C. 239 The rate at which GAP messages are transmitted is at the discretion 240 of the sender, and may fluctuate over time as well as differ per 241 application. Each message contains, for each application it 242 describes, a lifetime that informs the receiver how long to wait 243 before discarding the data for that application. 245 The GAP itself provides no fragmentation and reassembly mechanisms. 246 In the event that an application wishes to send larger chunks of data 247 via GAP messages than fall within the limits of packet size, it is 248 the responsibility of the application to fragment its data 249 accordingly. It is the responsibility of the application and the 250 network operator to ensure that the use of the GAP protocol does not 251 congest the link to the peer. 253 The GAP is designed to run over a unidirectional channel. However, 254 where the channel is bidirectional, communication may be optimized 255 through the use of a number of messages defined for transmission from 256 the receiver back to the sender. These are optimizations and are not 257 required for protocol operation. 259 3. Message Format 261 An Associated Channel Header (ACH) Channel Type has been allocated 262 for the GAP as follows: 264 Protocol Channel Type 265 ---------------------------- -------------------- 266 G-ACh Advertisement Protocol 0xXXXX (TBD by IANA) 268 For this Channel Type, as noted in [I-D.ietf-mpls-retire-ach-tlv] the 269 ACH SHALL NOT be followed by the ACH TLV Header defined in[RFC5586]. 271 Fields in this document shown as Reserved or Resv are reserved for 272 future specification and MUST be set to zero. All integer values for 273 fields defined in this document SHALL be encoded in network byte 274 order. 276 A GAP message consists of a fixed header followed by a GAP payload. 277 The payload of a GAP message is an Application Data Block (ADB) 278 consisting of one or more block elements. Each block element 279 contains an application identifier, a lifetime, and a series of zero 280 or more TLV objects for the application it describes. 282 Malformed GAP messages MUST be discarded by the receiver, although an 283 error MAY be logged. If the error is logged remotely, a suitable 284 form of rate limiting SHOULD be used to prevent excessive logging 285 messages being transmitted over the network. 287 Implementations of this protocol version MUST set reserved fields in 288 the message formats that follow, to all zero bits when sending and 289 ignore any value when receiving messages. 291 3.1. GAP Message Format 293 The following figure shows the format of a G-ACh Advertisement 294 Protocol message, which follows the Associated Channel Header (ACH): 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |Version| Reserved | Message Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Message Identifier | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Timestamp | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 ~ Application Data Block (ADB) ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 1: GAP Message Format 311 The meanings of the fields are: 313 Version (4 bits): Protocol version. This is set to zero. 315 Reserved (12 bits): MUST be sent as zero. 317 Message Length (16 bits): Size in octets of this message, i.e. of 318 the portion of the packet following the Associated Channel Header 320 Message Identifier (MI) (32 bits): Unique identifier of this 321 message. For disambiguation, a sender MUST NOT re-use an MI over 322 a given channel until it is confident that all ADBs associated 323 with have been expired by the receiver. The sole purpose of this 324 field is duplicate detection in the event of a message burst 325 (Section 5.1). 327 Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp, 328 as specified in Section 6 of [RFC5905]. 330 3.2. Applications Data Block 332 An ADB consists of one or more elements of the following format: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Application ID | Element Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Lifetime | Reserved | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 ~ TLV Object ~ 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 ~ TLV Object ~ 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 . . 346 . . 347 . . 349 Figure 2: Application Data Block Element 351 Application ID (16 bits) : Identifies the application this element 352 describes; an IANA registry has been created to track the values 353 for this field. More than one block element with the same 354 Application ID may be present in the same ADB, and block elements 355 with different Application IDs may also be present in the same 356 ADB. The protocol rules for the mechanism, including what ADB 357 elements are present and which TLVs are contained in an ADB 358 element, are to be defined in the document that specifies the 359 application-specific usage. 361 Element Length (16 bits): Specifies the total length in octets of 362 this block element (including the Application ID and Element 363 Length fields). 365 Lifetime field (16 bits): Specifies how long, in seconds, the 366 receiver should retain the data in this message (i.e. it specifies 367 the lifetime of the static data carried in the TLV set of this 368 ADB). For TLVs not carrying static data, the Lifetime is no 369 significance. The sender of a GAP message indicates this by 370 setting the Lifetime field to zero. If the Lifetime is zero, TLVs 371 in this ADB are processed by the receiver and the data associated 372 with these TLV types is immediately marked as expired. If the ADB 373 contains no TLVs, the receiver expires all data associated TLVs 374 previously sent to this application. 376 The remainder of the Application Data Block element consists of a 377 sequence of zero or more TLV objects which use the format defined in 378 Section 3.3. 380 The scope of an ADB is an application instance attached to a specific 381 channel between a specific source-destination pair, and the lifetime 382 field specifies the lifetime of the associated ADB in that specific 383 context. 385 3.3. TLV Object Format 387 GAP TLV objects use the following format: 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type | Reserved | Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 ~ Value ~ 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 3: TLV Object Format 399 Type (8 bits): Identifies the TLV Object and is scoped to a 400 specific application; each application creates an IANA registry to 401 track its Type values. 403 Reserved (8 bits): MUST be sent as zero. 405 Length (16 bits): The length in octets of the value field. The 406 value field need not be padded to provide alignment. 408 GAP messages do not contain a checksum. If validation of message 409 integrity is desired, the authentication procedures in Section 6 410 should be used. 412 4. G-ACh Advertisement Protocol TLVs 414 The GAP supports several TLV objects related to its own operation via 415 the Application ID 0x0000. These objects represent metadata and 416 processing instructions rather than static data that is meant to be 417 retained. When an ADB element for the GAP is present in a GAP 418 message, it MUST precede other elements. This is particularly 419 important in the case for the correct operation of the flush message. 421 Any application using the GAP inherits the ability to use facilities 422 provide by Application 0x0000. 424 Application 0x0000 GAP messages MUST be processed in the order in 425 which they are received. 427 4.1. Source Address TLV 429 The Source Address object identifies the sending device and possibly 430 the transmitting interface and the channel; it has the following 431 format: 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type=0 | Reserved | Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Reserved (16 bits) | Address Family (16 bits) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 ~ Address ~ 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 4: Source Address TLV Format 445 The Address Family field indicates the type of the address; it SHALL 446 be set to one of the assigned values in the IANA "Address Family 447 Numbers" registry. 449 In IP networks a Source Address SHOULD be included in GAP messages 450 and set to an IP address of the sending device; when the channel is a 451 link, this address SHOULD be an address of the transmitting 452 interface. 454 In non-IP MPLS-TP networks a Source Address SHOULD be included in GAP 455 messages and set to the endpoint identifier of the channel. The 456 formats of these channel identifiers SHALL be as given in Sections 457 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and 458 Length fields shown in those sections). IANA has allocated Address 459 Family Numbers for these identifiers; see Section 10.2. 461 On multipoint channels a Source Address TLV is REQUIRED. 463 4.2. GAP Request TLV 465 This object is a request by the sender for the receiver to transmit 466 an immediate unicast GAP update to the sender. If the Length field 467 is zero, this signifies that an update for all applications is 468 requested. Otherwise, the value field specifies the applications for 469 which an update is requested, in the form of a sequence of 470 Application IDs: 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=1 | Reserved | Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Application ID 1 | Application ID 2 | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 . . 480 . . 481 . . 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Application ID N-1 | Application ID N | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 5: GAP Request TLV Format 488 The intent of this TLV is to request the immediate transmission of 489 data following a local event such as a restart rather than waiting 490 for a periodic update. Applications need to determine what 491 information is meaningful to send in response to such a request. The 492 inclusion of an Application IDs in a Request TLV does not guarantee 493 that the response will provide information for that application. The 494 responder may also include information for applications not included 495 in the request. A receiver SHOULD discard GAP Request messages that 496 arrive at a rate in excess of that which is considered reasonable for 497 the application. 499 For an application 0x0000 GAP Request it is meaningful to respond 500 with the Source Address. 502 This TLV is considered to be part of the GAP protocol and thus does 503 not need to be retained. The reception of the TLV may however be 504 recorded for management purposes. 506 4.3. GAP Flush TLV 508 This object is an instruction to the receiver to flush the GAP data 509 for all applications associated with this (sender, channel) pair. It 510 is a null object, i.e. its Length is set to zero. 512 The GAP Flush instruction does not apply to data contained in the 513 message carrying the GAP Flush TLV object itself. Any application 514 data contained in the same message SHALL be processed and retained by 515 the receiver as usual. 517 The flush TLV type is 2. 519 This TLV is considered to be part of the GAP protocol and thus does 520 not need to be retained. The reception of the TLV may however be 521 recorded for management purposes. 523 4.4. GAP Suppress TLV 525 This object is a request to the receiver to cease sending GAP updates 526 to the transmitter over the current channel for the specified 527 duration. Duration is a 16 bit positive integer in units of seconds. 528 The receiver MAY accept and act on the request, MAY ignore the 529 request, or MAY resume transmissions at any time according to 530 implementation or configuration choices, and depending on local 531 pragmatics. The format of this object is as follows: 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type=3 | Reserved | Length | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Duration | Application ID 1 | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 . . 541 . . 542 . . 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Application ID N-1 | Application ID N | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 6: GAP Suppress TLV Format 549 If the Length is set to 2, i.e. if the list of Application IDs is 550 empty, then suppression of all GAP messages is requested; otherwise 551 suppression of only those updates pertaining to the listed 552 applications is requested. A duration of zero cancels any existing 553 suppress requests for the listed applications. 555 This object makes sense only for point-to-point channels or when the 556 sender is receiving unicast GAP updates. 558 4.5. GAP Authentication TLV 560 This object is used to provide authentication and integrity 561 validation for a GAP message. It has the following format: 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type=4 | Reserved | Length | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Reserved | Key ID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 ~ Authentication Data ~ 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Figure 7: GAP Authentication TLV Format 575 The data and procedures associated with this object are explained in 576 Section 6. 578 5. Operation 580 5.1. Message Transmission 582 G-ACh Advertisement Protocol message transmission SHALL operate on a 583 per-data-channel basis and be configurable by the operator 584 accordingly. 586 Because GAP message transmission may be active for many logical 587 channels on the same physical interface, message transmission timers 588 SHOULD be randomized across the channels supported by a given 589 interface so as to reduce the likelihood of large synchronized 590 message bursts. 592 The Message Identifier (MI) uniquely identifies this message and its 593 value is set at the sender's discretion. It MUST NOT be assumed to 594 be a sequence number. The scope of an MI is a channel between a 595 specific source-destination pair. 597 The Timestamp field SHALL be set to the time at which this message is 598 transmitted. 600 The Lifetime field of each Application Data Block element SHALL be 601 set to the number of seconds the receiver is advised to retain the 602 data associated with this message and application. 604 When the transmitter wishes the data previously sent in an ADB 605 element to persist then it must refresh the ADB element by sending 606 another update. Refresh times SHOULD be set in such a way that at 607 least three updates will be sent prior to Lifetime expiration. For 608 example, if the Lifetime is set to 210 seconds, then updates should 609 be sent at least once every 60 seconds. 611 A sender may signal that previously sent data SHOULD be marked as 612 expired by setting the ADB element lifetime to zero as previously 613 described in Section 3 . 615 In some cases an application may desire additional reliability for 616 the delivery of some of its data. When this is the case, the 617 transmitter MAY send several (for example three) instances of the 618 message in succession, separated by a delay appropriate to, or 619 specified by, the application. For example this procedure might be 620 invoked when sending a flush instruction following device reset. The 621 expectation is that the receiver will detect duplicate messages using 622 the MI. 624 5.2. Message Reception 626 G-ACh Advertisement Protocol message reception SHALL operate on a 627 per-data-channel basis and be configurable by the operator 628 accordingly. 630 Upon receiving a G-ACh Advertisement Protocol message that contains 631 data for some application X, the receiver determines whether it can 632 interpret X-data. If it cannot, then the receiver MAY retain this 633 data for the number of seconds specified by the Lifetime field; 634 although it cannot parse this data, it may still be of use to the 635 operator. 637 If the receiver can interpret X-data, then it processes the data 638 objects accordingly, retaining the data associated with those that 639 represent static data for the number of seconds specified by the 640 Lifetime field. If the lifetime is zero, such data is immediately 641 marked as expired, and if no TLVs are specified all data associated 642 with previously received TLVs is marked as expired Section 3. If one 643 of the received TLV objects has the same Type as a previously 644 received TLV then the data from the new object SHALL replace the data 645 associated with that Type unless the X specification dictates a 646 different behavior. 648 The received data is made available to local applications that 649 required it and are locally authorized to view it. The method for 650 doing this is local to the receiver and outside the scope of this 651 document. 653 The receiver MAY make use of the application data contained in a GAP 654 message to perform some level of auto-configuration, for example if 655 the application is an OAM protocol. The application SHOULD, however, 656 take care to prevent cases of oscillation resulting from each 657 endpoint attempting to adjust its configuration to match the other. 658 Any such auto-configuration based on GAP information MUST be disabled 659 by default. 661 The MI may be used to detect and discard duplicate messages. 663 6. Message Authentication 665 The GAP provides a means of authenticating messages and ensuring 666 their integrity. This is accomplished by attaching a GAP 667 Authentication TLV and including, in the Authentication Data field, 668 the output of a cryptographic hash function (known as a Message 669 Authentication Code (MAC)), the input to which is the message 670 together with a secret key known only to the sender and receiver. 671 Upon receipt of the message, the receiver computes the same MAC and 672 compares the result with the MAC in the message; if the MACs are not 673 equal, the message is discarded. Use of GAP message authentication 674 is RECOMMENDED. 676 The remainder of this section gives the details of this procedure, 677 which is based on the procedures for generic cryptographic 678 authentication for the Intermediate System to Intermediate System 679 (IS-IS) routing protocol as described in [RFC5310]. 681 6.1. Authentication Key Identifiers 683 An Authentication Key Identifier (Key ID) is a 16-bit tag shared by 684 the sender and receiver that identifies a set of authentication 685 parameters. These parameters are not sent over the wire; they are 686 assumed to be associated, on each node, with the Key ID by external 687 means, such as via explicit operator configuration or a separate key- 688 exchange protocol. Multiple Key IDs may be active on the sending and 689 receiving nodes simultaneously, in which case the sender locally 690 selects a Key ID from this set to use in an outbound message. This 691 capability facilitates key migration in the network. 693 The parameters associated with a Key ID are: 695 o Authentication Algorithm: This signifies the authentication 696 algorithm to use to generate or interpret authentication data. At 697 present, the following values MAY supported: HMAC-SHA-1, HMAC- 698 SHA-256. HMAC-SHA-1 MUST be supported. 700 o Authentication Keystring: A secret octet string that forms the 701 basis for the cryptographic key used by the Authentication 702 Algorithm. It SHOULD NOT be a human memorable string. 703 Implementations MUST be able to use random binary values of the 704 appropriate length as a keystring. 706 Implementors SHOULD consider the use of 707 [I-D.ietf-karp-crypto-key-table] for key management. If used, 708 authenticated information sent over the gap MUST only considered 709 valid if it was sent during the KARP interval between 710 SendLifetimeStart and SendLifeTimeEnd. However, if the GAP TLV used 711 to send it expires before the KARP SendLifetimeStart, then 712 information is never used, and if it expires before KARP 713 SendNotAfter, the key becomes invalid on expiry of the GAP TLV. 715 At the time of this writing, mechanisms for dynamic key management in 716 the absence of IP are not available. Key management in such 717 environments therefore needs to take place via the equipment 718 management system or some other out of band service. The MPLS layer 719 in a network is normally isolated from direct access by users and 720 thus is a relatively protected environment. Thus key turnover is a 721 relatively infrequent event. 723 6.2. Authentication Process 725 The authentication process for GAP messages is straightforward. 726 First, a Key ID is associated on both the sending and receiving nodes 727 with a set of authentication parameters. Following this, when the 728 sender generates a GAP message, it sets the Key ID field of the GAP 729 Authentication TLV accordingly. (The length of the Authentication 730 Data field is also known at this point, because it is a function of 731 the Authentication Algorithm.) The sender then computes a MAC for 732 the message as described in Section 6.3, and fills the Authentication 733 Data field of the GAP Authentication TLV with the MAC overrighting 734 the zeros used in computation. The message is then sent. 736 When the message is received, the receiver computes a MAC for it as 737 described below, again setting the Authentication Data field of the 738 GAP Authentication TLV to all zeros before computing the MAC. The 739 receiver compares its computed MAC to the MAC received in the 740 Authentication Data field. If the two MACs are equal, authentication 741 of the message is considered to have succeeded; otherwise it is 742 considered to have failed. 744 This process suffices to ensure the authenticity and integrity of 745 messages, but is still vulnerable to a replay attack, in which a 746 third party captures a message and sends it on to the receiver at 747 some later time. The GAP message header contains a Timestamp field 748 which can be used to protect against replay attacks. To achieve this 749 protection, the receiver checks that the time recorded in the 750 timestamp field of a received and authenticated GAP message 751 corresponds to the current time, within a reasonable tolerance that 752 allows for message propagation delay, and accepts or rejects the 753 message accordingly. Clock corrections SHOULD be monotonic to avoid 754 replay attack unless operator intervention overrides this to achieve 755 a faster convergence with current time. 757 If the clocks of the sender and receiver are not synchronized with 758 one another, then the receiver must perform the replay check against 759 its best estimate of the current time according to the sender's 760 clock. The timestamps that appear in GAP messages can be used to 761 infer the approximate clock offsets of senders and, while this does 762 not yield high-precision clock synchronization, it suffices for 763 purposes of the replay check with an appropriately chosen tolerance. 765 6.3. MAC Computation 767 The HMAC procedure described in [RFC2104] is used to compute the MAC. 769 The Authentication Data field of the GAP Authentication TLV is set to 770 all zeros. The MAC is then computed over the entire GAP message as 771 shown in Figure 1. 773 Where there is less data than is needed for the MAC computation, a 774 value of zero MUST be used. 776 The length of the Authentication Data field is always less than or 777 equal to the message digest size of the specific hash function that 778 is being used, however the implementer needs to consider that 779 although this decreases the size of the message, it results in a 780 corresponding reduction in the strength of the assurance provided. 782 MAC truncation is NOT RECOMMENDED. 784 7. Link-Layer Considerations 786 When the GAP is used to support device discovery on a data link, GAP 787 messages must be sent in such a way that they can be received by 788 other listeners on the link without the sender first knowing the 789 link-layer addresses of the listeners. In short, they must be 790 multicast. Considerations for multicast MPLS encapsulation are 791 discussed in [RFC5332]. For example, Section 8 of [RFC5332] 792 describes how destination Ethernet MAC addresses are selected for 793 multicast MPLS packets. Since a GAP packet transmitted over a data 794 link contains just one label, the G-ACh Label (GAL) with label value 795 13, the correct destination Ethernet address for frames carrying GAP 796 packets intended for device discovery, according to these selection 797 procedures, is 01-00-5e-80-00-0d. 799 8. Managability Considerations 801 The data sent and received by this protocol MUST be made accessible 802 for inspection by network operators, and where local configuration is 803 updated by the received information, it MUST be clear why the 804 configured value has been changed. This allows the operator to 805 determine the operational parameters currently in use and to 806 understand when local configuration has been superseded by inbound 807 parameters received from its peer. The persistence of data 808 advertised by this protocol is applications specific, but in general 809 SHOULD be persistent across restarts. To prevent stale information 810 or information from a former peer causing incorrect operation, 811 received advertisements MUST be discarded across restarts. If the 812 received values change, the new values MUST be used and the change 813 made visible to the network operators. 815 All applications MUST be disabled by default and need be enabled by 816 the operator if required. 818 9. Security Considerations 820 G-ACh Advertisement Protocol messages contain information about the 821 sending device and its configuration, which is sent in cleartext over 822 the wire. If an unauthorized third party gains access to the MPLS 823 data plane or the lower network layers between the sender and 824 receiver, it can observe this information. In general, however, the 825 information contained in GAP messages is no more sensitive than that 826 contained in other protocol messages, such as routing updates, which 827 are commonly sent in cleartext. No attempt is therefore made to 828 guarantee confidentiality of GAP messages. Therefore the GAP MUST 829 NOT be used to send TLVs in cleartext where the value concerned 830 requires confidentiality, for example, GAP or application TLVs 831 containing 'bare' cryptographic keying material. Applications which 832 require confidentiality will need to implement a suitable 833 confidentiality method. 835 A more significant potential threat is the transmission of GAP 836 messages by unauthorized sources, or the unauthorized manipulation of 837 messages in transit; this can disrupt the information receivers hold 838 about legitimate senders. To protect against this threat, message 839 authentication procedures are specified in Section 6 of this document 840 that enable receivers to ensure the authenticity and integrity of GAP 841 messages. These procedures include the means to protect against 842 replay attacks, in which a third party captures a legitimate message 843 and "replays" it to a receiver at some later time. 845 10. IANA Considerations 847 10.1. Associated Channel Type Allocation 849 This document requests that IANA allocate an entry in the "Pseudowire 850 Associated Channel Types" registry [RFC5586] (currently located 851 within the "Pseudowire Name Spaces (PWE3)" registry) for the "G-ACh 852 Advertisement Protocol", as follows: 854 Value Description TLV Follows Reference 855 --------- ---------------------------- ----------- ------------ 856 XXXX(TBD) G-ACh Advertisement Protocol No (this draft) 858 The reader should note that the "TLV Follows" column in the registry 859 is in the process of being deleted [I-D.ietf-mpls-retire-ach-tlv]. 861 10.2. Allocation of Address Family Numbers 863 IANA is requested to allocate three entries from the Standards Track 864 range in the "Address Family Numbers" registry for MPLS-TP Section, 865 LSP, and Pseudowire endpoint identifiers, per Section 4.1. The 866 allocations are: 868 Number Description Reference 869 ------ -------------------------------------- ------------ 870 (TBD) MPLS-TP Section Endpoint Identifier (this draft) 871 (TBD) MPLS-TP LSP Endpoint Identifier (this draft) 872 (TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft) 874 10.3. Creation of G-ACh Advertisement Protocol Application Registry 875 This document requests that IANA create a new registry, "G-ACh 876 Advertisement Protocol Applications" in the "Pseudowire Name Spaces 877 (PWE3)" registry, with fields and initial allocations as follows: 879 Application ID Description Reference 880 -------------- ---------------------------- ------------ 881 0x0000 G-ACh Advertisement Protocol (this draft) 883 The range of the Application ID field is 0x0000 - 0xFFFF. 885 The allocation policy for this registry is IETF Review. 887 10.4. Creation of G-ACh Advertisement Protocol TLV Registry 889 This document requests that IANA create a new registry, "G-ACh 890 Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the 891 "Pseudowire Name Spaces (PWE3)" registry, with fields and initial 892 allocations as follows: 894 Type Name Type ID Reference 895 ------------------ ------- ------------ 896 Source Address 0 (this draft) 897 GAP Request 1 (this draft) 898 GAP Flush 2 (this draft) 899 GAP Suppress 3 (this draft) 900 GAP Authentication 4 (this draft) 902 The range of the Type ID field is 0 - 255. 904 The allocation policy for this registry is IETF Review. 906 11. Acknowledgements 908 We thank Adrian Farrel for his valuable review comments on this 909 document. 911 12. References 913 12.1. Normative References 915 [I-D.ietf-karp-crypto-key-table] 916 Housley, R., Polk, T., Hartman, S., and D. Zhang, 917 "Database of Long-Lived Symmetric Cryptographic Keys", 918 draft-ietf-karp-crypto-key-table-07 (work in progress), 919 March 2013. 921 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 922 Hashing for Message Authentication", RFC 2104, February 923 1997. 925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 926 Requirement Levels", BCP 14, RFC 2119, March 1997. 928 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 929 Multicast Encapsulations", RFC 5332, August 2008. 931 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 932 Associated Channel", RFC 5586, June 2009. 934 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 935 Time Protocol Version 4: Protocol and Algorithms 936 Specification", RFC 5905, June 2010. 938 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 939 Connectivity Verification, Continuity Check, and Remote 940 Defect Indication for the MPLS Transport Profile", RFC 941 6428, November 2011. 943 12.2. Informative References 945 [I-D.ietf-mpls-retire-ach-tlv] 946 Farrel, A. and S. Bryant, "Retiring TLVs from the 947 Associated Channel Header of the MPLS Generic Associated 948 Channel", draft-ietf-mpls-retire-ach-tlv-00 (work in 949 progress), May 2013. 951 [I-D.ietf-mpls-tp-ethernet-addressing] 952 Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop 953 Ethernet Addressing", draft-ietf-mpls-tp-ethernet- 954 addressing-07 (work in progress), April 2013. 956 [LLDP] IEEE, ., "Station and Media Access Control Connectivity 957 Discovery (802.1AB)", September 2009. 959 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 960 converting network protocol addresses to 48.bit Ethernet 961 address for transmission on Ethernet hardware", STD 37, 962 RFC 826, November 1982. 964 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 965 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 966 September 2007. 968 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 969 Connectivity Verification (VCCV): A Control Channel for 970 Pseudowires", RFC 5085, December 2007. 972 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 973 and M. Fanto, "IS-IS Generic Cryptographic 974 Authentication", RFC 5310, February 2009. 976 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 977 "Bidirectional Forwarding Detection (BFD) for MPLS Label 978 Switched Paths (LSPs)", RFC 5884, June 2010. 980 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 981 Berger, "A Framework for MPLS in Transport Networks", RFC 982 5921, July 2010. 984 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 985 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 986 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 988 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 989 Measurement for MPLS Networks", RFC 6374, September 2011. 991 Authors' Addresses 993 Dan Frost 994 Cisco Systems 996 Email: danfrost@cisco.com 998 Stewart Bryant 999 Cisco Systems 1001 Email: stbryant@cisco.com 1003 Matthew Bocci 1004 Alcatel-Lucent 1006 Email: matthew.bocci@alcatel-lucent.com