--- 1/draft-ietf-mpls-gach-adv-05.txt 2013-02-13 03:00:57.595791003 +0100 +++ 2/draft-ietf-mpls-gach-adv-06.txt 2013-02-13 03:00:57.631791458 +0100 @@ -1,20 +1,20 @@ MPLS D. Frost Internet-Draft S. Bryant Intended status: Standards Track Cisco Systems -Expires: August 9, 2013 M. Bocci +Expires: August 16, 2013 M. Bocci Alcatel-Lucent - February 5, 2013 + February 12, 2013 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol - draft-ietf-mpls-gach-adv-05 + draft-ietf-mpls-gach-adv-06 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 August 9, 2013. + This Internet-Draft will expire on August 16, 2013. Copyright Notice Copyright (c) 2013 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 @@ -56,47 +56,47 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8 + 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 9 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 9 - 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9 + 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 10 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 10 - 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 10 + 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 11 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 11 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 12 - 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 12 - 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 13 - 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 14 + 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 13 + 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 14 + 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 14 + 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 15 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 15 - 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 16 - 8. Managability Considerations . . . . . . . . . . . . . . . . . 16 + 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 17 + 8. Managability Considerations . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Associated Channel Type Allocation . . . . . . . . . . . . 17 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 10.1. Associated Channel Type Allocation . . . . . . . . . . . . 18 10.2. Allocation of Address Family Numbers . . . . . . . . . . . 18 10.3. Creation of G-ACh Advertisement Protocol Application - Registry . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 18 + Registry . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The MPLS Generic Associated Channel (G-ACh) is defined and described in [RFC5586]. It provides an auxiliary logical data channel over which a variety of protocols may flow. Each such data channel is associated with an MPLS Label Switched Path (LSP), a pseudowire, or a section (link). An important use of the G-ACh and the protocols it supports is to provide Operations, Administration, and Maintenance (OAM) capabilities for the associated LSP, pseudowire, or section. @@ -255,22 +255,25 @@ Header defined in [RFC5586]. Fields in this document shown as Reserved or Resv are reserved for future specification and MUST be set to zero. All integer values for fields defined in this document SHALL be encoded in network byte order. A GAP message consists of a fixed header followed by a GAP payload. The payload of a GAP message is an Application Data Block (ADB) consisting of one or more block elements. Each block element - contains an application identifier, a lifetime, and a series of TLV - objects for the application it describes. + contains an application identifier, a lifetime, and a series of zero + or more TLV objects for the application it describes. + + Malformed GAP messages MUST be discarded by the receiver, although an + error MAY be logged. The following figure shows the format of a G-ACh Advertisement Protocol message, which follows the Associated Channel Header (ACH): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Reserved | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier | @@ -312,23 +315,34 @@ ~ TLV Object ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . Figure 2: 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. The Element Length field specifies the total - length in octets of this block element (including the Application ID - and Element Length fields). + values for this field. More than one block element with the same + Application ID may be present in the same ADB, and block elements + with different Application IDs may also be present in the same ADB. + The protocol rules for the mechanism, including what ADB elements are + present and which TLVs are contained in an ADB element, are to be + defined in the document that specifies the application-specific + usage. + + Editors note we prefer ", are to be defined in the application's + specification." + + 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 (i.e. it specifies the lifetime of the static data carried in the TLV set of this ADB). For TLVs not carrying static data the Lifetime is of no significance. If the Lifetime is zero, TLVs in this ADB are processed by the receiver and the data associated with these TLV types is immediately marked as expired. If the ADB contains no TLVs, the receiver expires all data associated TLVs previously sent to this application. The scope of the Lifetime is the source-channel-application tuple. @@ -342,21 +356,22 @@ | Type | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: TLV Object Format 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. + Value field. The value field need not be padded to provide + alignment. 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. These objects represent metadata and processing instructions rather than static data that is meant to be @@ -445,23 +460,25 @@ 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. The flush TLV type is 2. 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 - duration (in seconds). The request is strictly advisory: the - receiver SHOULD accept and act on the request, but MAY override it at - any time. The format of this object is as follows: + duration (in seconds). The receiver MAY accept and act on the + request, MAY ignore the request, or MAY resume transmissions at any + time according to implementation or configuration choices, and + depending on local pragmatics. The format of this object is as + follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3 | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration | Application ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . @@ -516,34 +533,41 @@ message bursts. The Message Identifier (MI) uniquely identifies this message and its value is set at the sender's discretion. The Timestamp field SHALL be set to the time at which this message is transmitted. The Lifetime field of each Application Data Block element SHALL be set to the number of seconds the receiver is advised to retain the - data associated with this message and application. 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 at least 210 seconds would typically - used. A sender deletes previously sent data by using the TLV - lifetime mechanism as previously described in Section 3 . + data associated with this message and application. - 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 - device reset. + When the transmitter wishes the data previously sent in an ADB + element to persist then it must refresh the ADB element by sending + another update. Refresh times SHOULD be set in such a way that at + least three updates will be sent prior to Lifetime expiration. For + example, if the Lifetime is set to 210 seconds, then updates should + be sent at least once every 60 seconds. + + A sender may signal that previously sent data SHOULD be marked as + expired by setting the ADB element lifetime to zero as previously + described in Section 3 . + + In some cases an application may desire additional reliability for + the delivery of some of its data. When this is the case, the + transmitter MAY send several (for example three) instances of the + message in succession, separated by a delay appropriate to, or + specified by, the application. For example this procedure might be + invoked when sending a flush instruction following device reset. The + expectation is that the receiver will detect duplicate messages using + the MI. 5.2. Message Reception 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 @@ -606,20 +630,28 @@ 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 cryptographic key used by the Authentication Algorithm. Implementors SHOULD consider the use of [I-D.ietf-karp-crypto-key-table] for key management. + At the time of this writing, mechanisms for dynamic key management in + the absence of IP are not available. Key management in such + environments therefore needs to take place via the equipment + management system or some other out of band service. The MPLS layer + in a network is normally isolated from direct access by users and + thus is a relatively protected environment. Thus key turnover is a + relatively infrequent event. + 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 the message as described in Section 6.3 , and fills the