--- 1/draft-ietf-mpls-gach-adv-01.txt 2012-05-28 12:16:08.621508810 +0200 +++ 2/draft-ietf-mpls-gach-adv-02.txt 2012-05-28 12:16:08.661510344 +0200 @@ -1,20 +1,20 @@ MPLS D. Frost, Ed. Internet-Draft S. Bryant, Ed. Intended status: Standards Track Cisco Systems -Expires: November 24, 2012 M. Bocci, Ed. +Expires: November 26, 2012 M. Bocci, Ed. Alcatel-Lucent - May 23, 2012 + May 25, 2012 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol - draft-ietf-mpls-gach-adv-01 + draft-ietf-mpls-gach-adv-02 Abstract The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the @@ -31,21 +31,21 @@ 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 November 24, 2012. + This Internet-Draft will expire on November 26, 2012. 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 @@ -55,38 +55,38 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 8 - 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 9 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 9 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 10 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.1. G-ACh Advertisement Message Transmission . . . . . . . . . 11 - 5.2. G-ACh Advertisement Message Reception . . . . . . . . . . 11 + 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 11 + 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 11 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 12 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 12 - 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 12 + 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 13 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 13 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 9.1. Associated Channel Type Allocation . . . . . . . . . . . . 15 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Associated Channel Type Allocation . . . . . . . . . . . . 16 9.2. Allocation of Address Family Numbers . . . . . . . . . . . 16 9.3. Creation of G-ACh Advertisement Protocol Application Registry . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction @@ -111,21 +111,21 @@ information to validate or adjust their own configurations, and network operators can make use of it to diagnose faults and configuration inconsistencies between endpoints. The main principle guiding the design of the MPLS G-ACh advertisement protocol (GAP) is simplicity. The protocol provides a one-way method of distributing information about the sender. How this information is used by a given receiver is a local matter. The data elements distributed by the GAP are application-specific and, except for those associated with the GAP itself, are outside the scope of this - document. An IANA registry is created to allow GAP data elements to + document. An IANA registry is created to allow GAP applications to be defined as needed. 1.1. Motivation It is frequently useful in a network for a node to have general information about its adjacent nodes, i.e., those nodes to which it has links. At a minimum this allows a human operator or management application with access to the node to determine which adjacent nodes this node can see, which is helpful when troubleshooting connectivity problems. A typical example of an "adjacency awareness protocol" is @@ -141,21 +141,21 @@ layer. The G-ACh advertisement protocol presented in this document thus allows LSRs to exchange information of a similar sort to that supported by LLDP for Ethernet links. An important special case arises in networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] that do not also support IP: without IP, protocols for determining the Ethernet address of an adjacent MPLS node, such as the Address Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery [RFC4861], are not available. The G-ACh advertisement protocol can be used to discover the Ethernet - MAC addresses of MPLS nodes lacking IP capability + MAC addresses of MPLS-TP nodes lacking IP capability [I-D.ietf-mpls-tp-ethernet-addressing]. The applicability of the G-ACh advertisement protocol is not limited to link-layer adjacency, either in terms of message distribution or message content. The G-ACh exists for any MPLS LSP or pseudowire, so GAP messages can be exchanged with remote LSP or pseudowire endpoints. The content of GAP messages is extensible in a simple manner, and can include any kind of information that might be useful to MPLS LSRs connected by links, LSPs, or pseudowires. For example, in networks that rely on the G-ACh for OAM functions, GAP messages @@ -180,49 +180,55 @@ document are to be interpreted as described in [RFC2119]. 2. Overview The G-ACh Advertisement Protocol has a simple one-way mode of operation: a device configured to send information for a particular data channel (MPLS LSP, pseudowire, or section) transmits GAP messages over the G-ACh associated with the data channel. The payload of a GAP message is a collection of Type-Length-Value (TLV) objects, organized on a per-application basis. An IANA registry is - created to identify specific applications. + created to identify specific applications. Application TLV objects + primarily contain static data that the receiver is meant to retain + for a period of time, but may also represent metadata or special + processing instructions. Although one GAP message can contain data for several applications, the receiver maintains the data associated with each application separately. This enables the sender to transmit a targeted update that refreshes the data for a subset of applications without affecting the data of other applications. For example, a GAP message might be sent containing the following data: - Application A: A-TLV1, A-TLV2, A-TLV3 + Application A: A-TLV4, A-TLV15, A-TLV9 - Application B: B-TLV1 + Application B: B-TLV1, B-TLV3 - Application C: C-TLV1, C-TLV2 + Application C: C-TLV6, + + where the numbers are specific Type values. A second message might then be sent containing: - Application B: B-TLV1, B-TLV2 + Application B: B-TLV7, B-TLV3 - Upon receiving the second message, the receiver flushes the old data - for Application B and replaces it with the new data. The data - associated with Applications A and C from the first message is - retained. In other words, the GAP update granularity is per- - application, not per-message or per-TLV-object. + Upon receiving the second message, the receiver retains B-TLV1 from + the first message and adds B-TLV7 to its B-database. How it handles + the new B-TLV3 depends on the rules B has specified for this object + type; this object could replace the old one or be combined with it in + some way. The second message has no effect on the databases + maintained by the receiver for Applications A and C. The rate at which GAP messages are transmitted is at the discretion - of the sender, and may fluctuate over time as well as differ per- + of the sender, and may fluctuate over time as well as differ per application. Each message contains, for each application it describes, a lifetime that informs the receiver how long to wait before discarding the data for that application. The GAP itself provides no fragmentation and reassembly mechanisms. In the event that an application wishes to send larger chunks of data via GAP messages than fall within the limits of packet size, it is the responsibility of the application to fragment its data accordingly. @@ -292,91 +297,88 @@ ~ TLV Object ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . Application Data Block Element In this format, the Application ID identifies the application this element describes; an IANA registry has been created to track the - values for this field. Any two ADB elements in the same ADB SHALL - have distinct Application IDs. The Element Length field specifies - the total length in octets of this block element. The Lifetime field - specifies how long, in seconds, the receiver should retain the data - in this message. + values for this field. The Element Length field specifies the total + length in octets of this block element (including the Application ID + and Element Length fields). The Lifetime field specifies how long, + in seconds, the receiver should retain the data in this message. The remainder of the Application Data Block element consists of a - sequence of TLV objects, which are of the form: + sequence of one or more TLV objects, which are of the form: 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 | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Object Format - The Type field identifies the TLV Object; an IANA registry has been - created to track the values for this field, which are defined on a - per-application basis. The Length field specifies the length in - octets of the Value field. - - It is permissible for the sequence of TLV objects in an ADB element - to be empty. This is useful in conjunction with setting the Lifetime - to zero in order to instruct the receiver to flush all data - associated with this application. + The Type field identifies the TLV Object and is scoped to a specific + application; each application creates an IANA registry to track its + Type values. The Length field specifies the length in octets of the + Value field. GAP messages do not contain a checksum. If validation of message integrity is desired, the authentication procedures in Section 6 should be used. 4. G-ACh Advertisement Protocol TLVs The GAP supports several TLV objects related to its own operation via - the Application ID 0x0000. When an ADB element for the GAP is - present in a GAP message, it MUST precede other elements. + the Application ID 0x0000. These objects represent metadata and + processing instructions rather than static data that is meant to be + retained. When an ADB element for the GAP is present in a GAP + message, it MUST precede other elements. 4.1. Source Address TLV The Source Address object identifies the sending device and possibly the transmitting interface and the channel; it has 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 | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Address TLV Format The Address Family field indicates the type of the address; it SHALL - be set to one of the assigned values in the "IANA Address Family + be set to one of the assigned values in the IANA "Address Family Numbers" registry. - In IP networks the Source Address SHOULD be included in GAP messages + In IP networks a Source Address SHOULD be included in GAP messages and set to an IP address of the sending device; when the channel is a link, this address SHOULD be an address of the transmitting interface. - In non-IP MPLS-TP networks the Source Address SHOULD be included in - GAP messages and set to the endpoint identifier of the channel. The + In non-IP MPLS-TP networks a Source Address SHOULD be included in GAP + messages and set to the endpoint identifier of the channel. The formats of these channel identifiers SHALL be as given in Sections 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and - Length fields shown in those sections). + Length fields shown in those sections). IANA has allocated Address + Family Numbers for these identifiers; see Section 9.2. 4.2. GAP Request TLV This object is a request by the sender for the receiver to transmit an immediate unicast GAP update to the sender. If the Length field is zero, this signifies that an update for all applications is requested. Otherwise, the Value field specifies the applications for which an update is requested, in the form of a sequence of Application IDs: @@ -392,24 +394,22 @@ . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application ID N-1 | Application ID N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GAP Request TLV Format 4.3. GAP Flush TLV This object is an instruction to the receiver to flush the GAP data - for all applications associated with this sender. It is a null - object, i.e. its Length is set to zero. Note that data for a - specific application can be flushed by sending an update for the - application with the Lifetime set to zero. + for all applications associated with this (sender, channel) pair. It + is a null object, i.e. its Length is set to zero. The GAP Flush instruction does not apply to data contained in the message carrying the GAP Flush TLV object itself. Any application data contained in the same message SHALL be processed and retained by the receiver as usual. 4.4. GAP Suppress TLV This object is a request to the receiver to cease sending GAP updates to the transmitter over the current channel for the specified @@ -455,21 +455,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Authentication Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GAP Authentication TLV Format The data and procedures associated with this object are explained in Section 6. 5. Operation -5.1. G-ACh Advertisement Message Transmission +5.1. Message Transmission G-ACh Advertisement Protocol message transmission SHALL operate on a per-data-channel basis and be configurable by the operator accordingly. Because GAP message transmission may be active for many logical channels on the same physical interface, message transmission timers SHOULD be randomized across the channels supported by a given interface so as to reduce the likelihood of large synchronized message bursts. @@ -485,31 +485,43 @@ Lifetimes SHOULD be set in such a way that at least three updates will be sent prior to Lifetime expiration. For example, if updates are sent at least every 60 seconds, a Lifetime of 185 seconds may be used. In some cases additional reliability may be desired for the delivery of a GAP message. When this is the case, the RECOMMENDED procedure is to send three instances of the message in succession, separated by a delay appropriate to the application. This procedure SHOULD be used, if at all, only for messages that are in some sense - 'exceptional'; for example when sending a flush instruction following + exceptional; for example when sending a flush instruction following device reset. -5.2. G-ACh Advertisement Message Reception +5.2. Message Reception - Upon receiving a G-ACh Advertisement Protocol message containing data - for a set of applications, the receiver MUST discard any earlier data - retained for each application in the set, and SHOULD retain the new - data associated with each application in the set by this message for - the number of seconds specified by the Lifetime field, or until a - newer message describing the application is received. + G-ACh Advertisement Protocol message reception SHALL operate on a + per-data-channel basis and be configurable by the operator + accordingly. + + Upon receiving a G-ACh Advertisement Protocol message that contains + data for some application X, the receiver determines whether it can + interpret X-data. If it cannot, then the receiver MAY retain this + data for the number of seconds specified by the Lifetime field; + although it cannot parse this data, it may still be of use to the + operator. + + If the receiver can interpret X-data, then it processes the data + objects accordingly, retaining those that represent static data for + the number of seconds specified by the Lifetime field. If one of + these objects has the same Type as an object currently retained by + the receiver in its X-database, then the new object SHALL replace the + old object in the database unless the X specification dictates a + different behavior for this object type. The receiver MAY make use of the application data contained in a GAP message to perform some level of autoconfiguration, for example if the application is an OAM protocol. The implementation SHOULD, however, take care to prevent cases of oscillation resulting from each endpoint attempting to adjust its configuration to match the other. Any such autoconfiguration based on GAP information MUST be disabled by default. 6. Message Authentication @@ -541,21 +553,21 @@ capability facilitates key migration in the network. The parameters associated with a Key ID are: o Authentication Algorithm: This signifies the authentication algorithm to use to generate or interpret authentication data. At present, the following values are possible: HMAC-SHA-1, HMAC-SHA- 224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. o Authentication Keystring: A secret string that forms the basis for - the crytographic key used by the Authentication Algorithm. + the cryptographic key used by the Authentication Algorithm. 6.2. Authentication Process The authentication process for GAP messages is straightforward. First, a Key ID is associated on both the sending and receiving nodes with a set of authentication parameters. Following this, when the sender generates a GAP message, it sets the Key ID field of the GAP Authentication TLV accordingly. (The length of the Authentication Data field is also known at this point, because it is a function of the Authentication Algorithm.) The sender then computes a hash for @@ -699,22 +711,22 @@ Advertisement Protocol, as follows: Value Description TLV Follows Reference ----- ---------------------------- ----------- ------------ (TBD) G-ACh Advertisement Protocol No (this draft) 9.2. Allocation of Address Family Numbers This document requests that IANA allocate three entries in the Address Family Numbers registry for MPLS-TP Section, LSP, and - Pseudowire endpoint identifiers, based on Sections 3.5.1, 3.5.2, and - 3.5.3 of [RFC6428]. The allocations are: + Pseudowire endpoint identifiers, per Section 4.1. The allocations + are: Number Description Reference ------ -------------------------------------- ------------ (TBD) MPLS-TP Section Endpoint Identifier (this draft) (TBD) MPLS-TP LSP Endpoint Identifier (this draft) (TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft) 9.3. Creation of G-ACh Advertisement Protocol Application Registry This document requests that IANA create a new registry, "G-ACh @@ -770,24 +782,24 @@ Specification", RFC 5905, June 2010. [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011. 10.2. Informative References [I-D.ietf-mpls-tp-ethernet-addressing] - Frost, D., Bocci, M., and S. Bryant, "MPLS-TP Next-Hop + Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop Ethernet Addressing", - draft-ietf-mpls-tp-ethernet-addressing-00 (work in - progress), January 2012. + draft-ietf-mpls-tp-ethernet-addressing-01 (work in + progress), May 2012. [LLDP] IEEE, "Station and Media Access Control Connectivity Discovery (802.1AB)", September 2009. [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,