GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7212

Internet Engineering Task Force (IETF) D. Frost Request for Comments: 7212 Blue Sun Category: Standards Track S. Bryant ISSN: 2070-1721 Cisco Systems

                                                              M. Bocci
                                                        Alcatel-Lucent
                                                             June 2014
   MPLS Generic Associated Channel (G-ACh) Advertisement Protocol

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
 other endpoints of its capabilities and configuration parameters, or
 other application-specific information.  This information may then be
 used by the receiver to validate or adjust its local configuration,
 and by the network operator for diagnostic purposes.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7212.

Frost, et al. Standards Track [Page 1] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Frost, et al. Standards Track [Page 2] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
   1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   6
 2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
 3.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .   7
   3.1.  GAP Message Format  . . . . . . . . . . . . . . . . . . .   8
   3.2.  Applications Data Block . . . . . . . . . . . . . . . . .   9
   3.3.  TLV Object Format . . . . . . . . . . . . . . . . . . . .  10
 4.  G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . .  10
   4.1.  Source Address TLV  . . . . . . . . . . . . . . . . . . .  11
   4.2.  GAP Request TLV . . . . . . . . . . . . . . . . . . . . .  11
   4.3.  GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . .  12
   4.4.  GAP Suppress TLV  . . . . . . . . . . . . . . . . . . . .  13
   4.5.  GAP Authentication TLV  . . . . . . . . . . . . . . . . .  14
 5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   5.1.  Message Transmission  . . . . . . . . . . . . . . . . . .  14
   5.2.  Message Reception . . . . . . . . . . . . . . . . . . . .  15
 6.  Message Authentication  . . . . . . . . . . . . . . . . . . .  16
   6.1.  Authentication Key Identifiers  . . . . . . . . . . . . .  16
   6.2.  Authentication Process  . . . . . . . . . . . . . . . . .  17
   6.3.  MAC Computation . . . . . . . . . . . . . . . . . . . . .  18
 7.  Link-Layer Considerations . . . . . . . . . . . . . . . . . .  18
 8.  Manageability Considerations  . . . . . . . . . . . . . . . .  19
 9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   10.1.  Associated Channel Type Allocation . . . . . . . . . . .  20
   10.2.  Allocation of Address Family Numbers . . . . . . . . . .  20
   10.3.  Creation of G-ACh Advertisement Protocol Application
          Registry . . . . . . . . . . . . . . . . . . . . . . . .  20
   10.4.  Creation of G-ACh Advertisement Protocol TLV Registry  .  21
 11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
 12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
   12.1.  Normative References . . . . . . . . . . . . . . . . . .  21
   12.2.  Informative References . . . . . . . . . . . . . . . . .  22

Frost, et al. Standards Track [Page 3] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

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) [RFC6291] capabilities for the associated LSP, pseudowire, or
 section.  Examples of such capabilities include Pseudowire Virtual
 Circuit Connectivity Verification (VCCV) [RFC5085]; Bidirectional
 Forwarding Detection (BFD) for MPLS [RFC5884]; and MPLS packet loss,
 delay, and throughput measurement [RFC6374]; as well as OAM functions
 developed for the MPLS Transport Profile (MPLS-TP) [RFC5921].
 This document specifies procedures for an MPLS Label Switching Router
 (LSR) to advertise its capabilities and configuration parameters, or
 other application-specific information, to its peers over LSPs,
 pseudowires, and sections.  Receivers can then make use of this
 information to validate or adjust their own configurations, and
 network operators can make use of it to diagnose faults and
 configuration inconsistencies between endpoints.  Note that in this
 document the term "application" refers to an application that uses
 the protocol defined herein (and hence operates over the G-ACh), and
 it should not be confused with an end-user application.
 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 has been created to allow GAP
 applications to be defined as needed.
 The assignment of application identifiers and associated GAP
 parameters for protocols other than the GAP itself is outside the
 scope of this document.  Such assignments can be made in subsequent
 documents according to the IANA considerations specified here.

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; this is helpful when troubleshooting connectivity
 problems.  A typical example of an "adjacency awareness protocol" is

Frost, et al. Standards Track [Page 4] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 the Link Layer Discovery Protocol [LLDP], which can provide various
 pieces of information about adjacent nodes in Ethernet networks, such
 as system name, basic functional capabilities, link speed/duplex
 settings, and maximum supported frame size.  Such data is useful both
 for human diagnostics and for automated detection of configuration
 inconsistencies.
 In MPLS networks, the G-ACh provides a convenient link-layer-agnostic
 means for communication between LSRs that are adjacent at the link
 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.  The GAP, however, does not
 depend on the specific link-layer protocol in use, and it can be used
 to advertise information on behalf of any MPLS application.
 In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921]
 that do not also support IP, the normal protocols used to determine
 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.  One possible use of the G-ACh
 advertisement protocol is to discover the Ethernet media access
 control addresses of MPLS-TP nodes lacking IP capability [RFC7213].
 However, where it is anticipated that the only data that needs to be
 exchanged between LSRs over an Ethernet link are their Ethernet
 addresses, then the operator may instead choose to use LLDP for that
 purpose.
 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
 might be used to inform adjacent LSRs of a node's OAM capabilities
 and configuration parameters.

1.2. Terminology

 Term  Definition
 ----- -------------------------------------------
 G-ACh Generic Associated Channel
 GAL   G-ACh Label
 GAP   G-ACh Advertisement Protocol
 LSP   Label Switched Path
 OAM   Operations, Administration, and Maintenance

Frost, et al. Standards Track [Page 5] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

1.3. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this 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 has
 been 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 they may also represent metadata or
 special processing instructions.
 Each GAP message can contain data for several applications.  A sender
 may transmit a targeted update that refreshes the data for a subset
 of applications without affecting the data of other applications sent
 in a previous message.  GAP messages are processed in the order in
 which they are received.
 For example, a GAP message might be sent containing the following
 data:
    Application A: A-TLV4, A-TLV15, A-TLV9
    Application B: B-TLV1, B-TLV3
    Application C: C-TLV6,
 where the TLVx refers to an example GAP TLV.
 A second message might then be sent containing:
    Application B: B-TLV7, B-TLV3
 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.

Frost, et al. Standards Track [Page 6] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 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
 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.  It is the responsibility of the application and the
 network operator to ensure that the use of the GAP does not congest
 the link to the peer.
 The GAP is designed to run over a unidirectional channel.  However,
 where the channel is bidirectional, communication may be optimized
 through the use of a number of messages defined for transmission from
 the receiver back to the sender.  These are optimizations and are not
 required for protocol operation.

3. Message Format

 An Associated Channel Header (ACH) Channel Type has been allocated
 for the GAP as follows:
 Protocol                           Channel Type
 ---------------------------------- ------------
 G-ACh Advertisement Protocol       0x0059
 For this Channel Type, as noted in [RFC7026], the ACH SHALL NOT be
 followed by the ACH TLV 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 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.  If the error is logged remotely, a suitable
 form of rate limiting SHOULD be used to prevent excessive logging
 messages being transmitted over the network.

Frost, et al. Standards Track [Page 7] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 Implementations of this protocol version MUST set reserved fields in
 the message formats that follow to all zero bits when sending and
 ignore any value when receiving messages.

3.1. GAP Message Format

 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                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp                           |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                    Application Data Block (ADB)               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 1: GAP Message Format
 The meanings of the fields are:
    Version (4 bits): Protocol version.  This is set to zero.
    Reserved (12 bits): MUST be sent as zero.
    Message Length (16 bits): Size in octets of this message, i.e., of
    the portion of the packet following the Associated Channel Header.
    Message Identifier (MI) (32 bits): Unique identifier of this
    message.  For disambiguation, a sender MUST NOT reuse an MI over a
    given channel until it is confident that all ADBs associated with
    it have been expired by the receiver.  The sole purpose of this
    field is duplicate detection in the event of a message burst
    (Section 5.1).
    Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp,
    as specified in Section 6 of [RFC5905].

Frost, et al. Standards Track [Page 8] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

3.2. Applications Data Block

 An ADB consists of one or more elements of 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Application ID         |        Element Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Lifetime           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                          TLV Object                           ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                          TLV Object                           ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
               Figure 2: Application Data Block Element
    Application ID (16 bits): Identifies the application this element
    describes; an IANA registry has been created to track the 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.
    Element Length (16 bits): Specifies the total length in octets of
    this block element (including the Application ID and Element
    Length fields).
    Lifetime field (16 bits): 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.  The sender of a GAP message indicates this by
    setting the Lifetime field to zero.  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 with
    TLVs previously sent to this application.

Frost, et al. Standards Track [Page 9] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 The remainder of the Application Data Block element consists of a
 sequence of zero or more TLV objects that use the format defined in
 Section 3.3.
 The scope of an ADB element is an application instance attached to a
 specific channel between a specific source-destination pair, and the
 Lifetime field specifies the lifetime of the ADB element data in that
 specific context.

3.3. TLV Object Format

 GAP TLV objects use 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                             Value                             ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 3: TLV Object Format
    Type (8 bits): Identifies the TLV Object and is scoped to a
    specific application; each application creates an IANA registry to
    track its Type values.
    Reserved (8 bits): MUST be sent as zero.
    Length (16 bits): The length in octets of the 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
 retained.  When an ADB element for the GAP is present in a GAP
 message, it MUST precede other elements.  This is particularly
 important for the correct operation of the Flush message
 (Section 4.3).

Frost, et al. Standards Track [Page 10] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 Any application using the GAP inherits the ability to use facilities
 provided by Application 0x0000.
 Application 0x0000 GAP messages MUST be processed in the order in
 which they are received.

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=0    |    Reserved   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Reserved (16 bits)       |    Address Family (16 bits)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                            Address                            ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 4: 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
 Numbers" registry.
 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, 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).  IANA has allocated Address
 Family Numbers for these identifiers; see Section 10.2.
 On multipoint channels, a Source Address TLV is REQUIRED.

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

Frost, et al. Standards Track [Page 11] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 requested.  Otherwise, the Value field specifies the applications for
 which an update is requested, in the form of a sequence of
 Application IDs:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type=1    |    Reserved   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Application ID 1       |        Application ID 2       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Application ID N-1     |        Application ID N       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 5: GAP Request TLV Format
 The intent of this TLV is to request the immediate transmission of
 data following a local event such as a restart, rather than waiting
 for a periodic update.  Applications need to determine what
 information is meaningful to send in response to such a request.  The
 inclusion of an Application ID in a Request TLV does not guarantee
 that the response will provide information for that application.  The
 responder may also include information for applications not included
 in the request.  A receiver SHOULD discard GAP Request messages that
 arrive at a rate in excess of that which is considered reasonable for
 the application.
 For an Application ID 0x0000 GAP Request, it is meaningful to respond
 with the Source Address.
 This TLV is considered to be part of the GAP and thus does not need
 to be retained.  The reception of the TLV may however be recorded for
 management purposes.

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, 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.

Frost, et al. Standards Track [Page 12] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 The Flush TLV type is 2.
 This TLV is considered to be part of the GAP and thus does not need
 to be retained.  The reception of the TLV may however be recorded for
 management purposes.

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.  Duration is a 16-bit non-negative integer in units of
 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       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Application ID N-1     |        Application ID N       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 6: GAP Suppress TLV Format
 If the Length is set to 2, i.e., if the list of Application IDs is
 empty, then suppression of all GAP messages is requested; otherwise,
 suppression of only those updates pertaining to the listed
 applications is requested.  A duration of zero cancels any existing
 suppress requests for the listed applications.
 This object makes sense only for point-to-point channels or when the
 sender is receiving unicast GAP updates.

Frost, et al. Standards Track [Page 13] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

4.5. GAP Authentication TLV

 This object is used to provide authentication and integrity
 validation for a GAP message.  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=4    |    Reserved   |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Reserved             |            Key ID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                    Authentication Data                        ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 7: GAP Authentication TLV Format
 The data and procedures associated with this object are explained in
 Section 6.

5. Operation

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.
 The Message Identifier (MI) uniquely identifies this message and its
 value is set at the sender's discretion.  It MUST NOT be assumed to
 be a sequence number.  The scope of an MI is a channel between a
 specific source-destination pair.
 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.

Frost, et al. Standards Track [Page 14] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 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
 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 the data associated with those that
 represent static data for the number of seconds specified by the
 Lifetime field.  If the Lifetime is zero, such data is immediately
 marked as expired, and, if no TLVs are specified, all data associated
 with previously received TLVs is marked as expired (Section 3).  If
 one of the received TLV objects has the same Type as a previously
 received TLV, then the data from the new object SHALL replace the
 data associated with that Type unless the X specification dictates a
 different behavior.
 The received data is made available to local applications that
 require it and are locally authorized to view it.  The method for
 doing this is local to the receiver and outside the scope of this
 document.

Frost, et al. Standards Track [Page 15] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 The receiver MAY make use of the application data contained in a GAP
 message to perform some level of auto-configuration, for example, if
 the application is an OAM protocol.  The application SHOULD, however,
 take care to prevent cases of oscillation resulting from each
 endpoint attempting to adjust its configuration to match the other.
 Any such auto-configuration based on GAP information MUST be disabled
 by default.
 The MI may be used to detect and discard duplicate messages.

6. Message Authentication

 The GAP provides a means of authenticating messages and ensuring
 their integrity.  This is accomplished by attaching a GAP
 Authentication TLV and including, in the Authentication Data field,
 the output of a cryptographic hash function (known as a Message
 Authentication Code (MAC)), the input to which is the message
 together with a secret key known only to the sender and receiver.
 Upon receipt of the message, the receiver computes the same MAC and
 compares the result with the MAC in the message; if the MACs are not
 equal, the message is discarded.  Use of GAP message authentication
 is RECOMMENDED.
 The remainder of this section gives the details of this procedure,
 which is based on the procedures for generic cryptographic
 authentication for the Intermediate System to Intermediate System
 (IS-IS) routing protocol as described in [RFC5310].

6.1. Authentication Key Identifiers

 An Authentication Key Identifier (Key ID) is a 16-bit tag shared by
 the sender and receiver that identifies a set of authentication
 parameters.  These parameters are not sent over the wire; they are
 assumed to be associated, on each node, with the Key ID by external
 means, such as via explicit operator configuration or a separate key-
 exchange protocol.  Multiple Key IDs may be active on the sending and
 receiving nodes simultaneously, in which case the sender locally
 selects a Key ID from this set to use in an outbound message.  This
 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 MAY be supported: HMAC-SHA-1, HMAC-
    SHA-256.  HMAC-SHA-1 MUST be supported.

Frost, et al. Standards Track [Page 16] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 o  Authentication Keystring: A secret octet string that forms the
    basis for the cryptographic key used by the Authentication
    Algorithm.  It SHOULD NOT be a human-memorable string.
    Implementations MUST be able to use random binary values of the
    appropriate length as a keystring.
 Implementers SHOULD consider the use of [RFC7210] for key management.
 If used, authenticated information sent over the GAP MUST only
 considered valid if it was sent during the Keying and Authentication
 for Routing Protocols (KARP) interval between SendLifetimeStart and
 SendLifeTimeEnd.  However, if the GAP TLV used to send it expires
 before the KARP SendLifetimeStart, then information is never used; if
 it expires before KARP SendNotAfter, the key becomes invalid on
 expiry of the GAP TLV.
 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.  Therefore, key turnover
 is expected to be 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 MAC for
 the message as described in Section 6.3 and fills the Authentication
 Data field of the GAP Authentication TLV with the MAC, overwriting
 the zeros used in computation.  The message is then sent.
 When the message is received, the receiver computes a MAC for it as
 described below, again setting the Authentication Data field of the
 GAP Authentication TLV to all zeros before computing the MAC.  The
 receiver compares its computed MAC to the MAC received in the
 Authentication Data field.  If the two MACs are equal, authentication
 of the message is considered to have succeeded; otherwise, it is
 considered to have failed.
 This process suffices to ensure the authenticity and integrity of
 messages but is still vulnerable to a replay attack, in which a third
 party captures a message and sends it on to the receiver at some
 later time.  The GAP message header contains a Timestamp field, which

Frost, et al. Standards Track [Page 17] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 can be used to protect against replay attacks.  To achieve this
 protection, the receiver checks that the time recorded in the
 Timestamp field of a received and authenticated GAP message
 corresponds to the current time, within a reasonable tolerance that
 allows for message propagation delay, and it accepts or rejects the
 message accordingly.  Clock corrections SHOULD be monotonic to avoid
 replay attacks, unless operator intervention overrides the monotonic
 configuration setting to achieve a faster convergence with current
 time.
 If the clocks of the sender and receiver are not synchronized with
 one another, then the receiver must perform the replay check against
 its best estimate of the current time according to the sender's
 clock.  The timestamps that appear in GAP messages can be used to
 infer the approximate clock offsets of senders, and, while this does
 not yield high-precision clock synchronization, it suffices for
 purposes of the replay check with an appropriately chosen tolerance.

6.3. MAC Computation

 The HMAC procedure described in [RFC2104] is used to compute the MAC.
 The Authentication Data field of the GAP Authentication TLV is set to
 all zeros.  The MAC is then computed over the entire GAP message as
 shown in Figure 1.
 Where there is less data than is needed for the MAC computation, a
 value of zero MUST be used.
 The length of the Authentication Data field is always less than or
 equal to the message digest size of the specific hash function that
 is being used.  However, the implementer needs to consider that
 although MAC truncation decreases the size of the message, it results
 in a corresponding reduction in the strength of the assurance
 provided.
 MAC truncation is NOT RECOMMENDED.

7. Link-Layer Considerations

 When the GAP is used to support device discovery on a data link, GAP
 messages must be sent in such a way that they can be received by
 other listeners on the link without the sender first knowing the
 link-layer addresses of the listeners.  In short, they must be
 multicast.  Considerations for multicast MPLS encapsulation are
 discussed in [RFC5332].  For example, Section 8 of [RFC5332]
 describes how destination Ethernet MAC addresses are selected for
 multicast MPLS packets.  Since a GAP packet transmitted over a data

Frost, et al. Standards Track [Page 18] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 link contains just one label, the G-ACh Label (GAL) with label value
 13, the correct destination Ethernet address for frames carrying GAP
 packets intended for device discovery, according to these selection
 procedures, is 01-00-5e-80-00-0d.

8. Manageability Considerations

 The data sent and received by this protocol MUST be made accessible
 for inspection by network operators, and where local configuration is
 updated by the received information, it MUST be clear why the
 configured value has been changed.  This allows the operator to
 determine the operational parameters currently in use and to
 understand when local configuration has been superseded by inbound
 parameters received from its peer.
 In the event of a system restart, any GAP application data and peer
 state data that has been retained as a consequence of prior
 advertisements from GAP peers MUST be discarded; this prevents
 incorrect operation on the basis of stale data.
 All GAP applications MUST be disabled by default and need to be
 enabled by the operator if required.

9. Security Considerations

 G-ACh Advertisement Protocol messages contain information about the
 sending device and its configuration, which is sent in cleartext over
 the wire.  If an unauthorized third party gains access to the MPLS
 data plane or the lower network layers between the sender and
 receiver, it can observe this information.  In general, however, the
 information contained in GAP messages is no more sensitive than that
 contained in other protocol messages, such as routing updates, which
 are commonly sent in cleartext.  No attempt is therefore made to
 guarantee confidentiality of GAP messages.  Therefore, the GAP MUST
 NOT be used to send TLVs in cleartext where the value concerned
 requires confidentiality, for example, GAP or application TLVs
 containing 'bare' cryptographic keying material.  Applications that
 require confidentiality will need to implement a suitable
 confidentiality method.
 A more significant potential threat is the transmission of GAP
 messages by unauthorized sources, or the unauthorized manipulation of
 messages in transit; this can disrupt the information receivers hold
 about legitimate senders.  To protect against this threat, message
 authentication procedures (specified in Section 6) enable receivers
 to ensure the authenticity and integrity of GAP messages.  These

Frost, et al. Standards Track [Page 19] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 procedures include the means to protect against replay attacks in
 which a third party captures a legitimate message and "replays" it to
 a receiver at some later time.

10. IANA Considerations

10.1. Associated Channel Type Allocation

 IANA has allocated an entry in the "MPLS Generalized Associated
 Channel (G-ACh) Types (including Pseudowire Associated Channel
 Types)" registry for the "G-ACh Advertisement Protocol", as follows:
 Value  Description                  Reference
 ------ ---------------------------- ---------
 0x0059 G-ACh Advertisement Protocol This RFC
 The reader should note that the "TLV Follows" column in the registry
 has been deleted [RFC7026].

10.2. Allocation of Address Family Numbers

 IANA has allocated three entries from the Standards Track range in
 the "Address Family Numbers" registry for MPLS-TP Section, LSP, and
 Pseudowire endpoint identifiers, per Section 4.1.  The allocations
 are:
 Number Description                            Reference
 ------ -------------------------------------- ---------
 26     MPLS-TP Section Endpoint Identifier    This RFC
 27     MPLS-TP LSP Endpoint Identifier        This RFC
 28     MPLS-TP Pseudowire Endpoint Identifier This RFC

10.3. Creation of G-ACh Advertisement Protocol Application Registry

 IANA has created a new registry, "G-ACh Advertisement Protocol
 Application Registry" in the "Generic Associated Channel (G-ACh)
 Parameters" registry, with fields and initial allocations as follows:
 Application ID Description                  Reference
 -------------- ---------------------------- ---------
 0x0000         G-ACh Advertisement Protocol This RFC
 The range of the Application ID field is 0x0000 - 0xFFFF.
 The allocation policy for this registry is IETF Review.

Frost, et al. Standards Track [Page 20] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

10.4. Creation of G-ACh Advertisement Protocol TLV Registry

 IANA has created a new registry, "G-ACh Advertisement Protocol: GAP
 TLV Objects (Application ID 0)" in the "Generic Associated Channel
 (G-ACh) Parameters" registry, with fields and initial allocations as
 follows:
 Type Name          Type ID Reference
 ------------------ ------- ---------
 Source Address     0       This RFC
 GAP Request        1       This RFC
 GAP Flush          2       This RFC
 GAP Suppress       3       This RFC
 GAP Authentication 4       This RFC
 The range of the Type ID field is 0 - 255.
 The allocation policy for this registry is IETF Review.

11. Acknowledgements

 We thank Adrian Farrel for his valuable review comments on this
 document.

12. References

12.1. Normative References

 [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
            Hashing for Message Authentication", RFC 2104, February
            1997.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5332]  Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
            Multicast Encapsulations", RFC 5332, August 2008.
 [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
            Associated Channel", RFC 5586, June 2009.
 [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
            Time Protocol Version 4: Protocol and Algorithms
            Specification", RFC 5905, June 2010.

Frost, et al. Standards Track [Page 21] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 [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.
 [RFC7210]  Housley, R., Polk, T., Hartman, S., and D. Zhang,
            "Database of Long-Lived Symmetric Cryptographic Keys", RFC
            7210, April 2014.

12.2. Informative References

 [LLDP]     IEEE, "Station and Media Access Control Connectivity
            Discovery", IEEE 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,
            "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
            September 2007.
 [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
            Connectivity Verification (VCCV): A Control Channel for
            Pseudowires", RFC 5085, December 2007.
 [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
            and M. Fanto, "IS-IS Generic Cryptographic
            Authentication", RFC 5310, February 2009.
 [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
            "Bidirectional Forwarding Detection (BFD) for MPLS Label
            Switched Paths (LSPs)", RFC 5884, June 2010.
 [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
            Berger, "A Framework for MPLS in Transport Networks", RFC
            5921, July 2010.
 [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
            D., and S. Mansfield, "Guidelines for the Use of the "OAM"
            Acronym in the IETF", BCP 161, RFC 6291, June 2011.
 [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
            Measurement for MPLS Networks", RFC 6374, September 2011.

Frost, et al. Standards Track [Page 22] RFC 7212 MPLS G-ACh Advertisement Protocol June 2014

 [RFC7026]  Farrel, A. and S. Bryant, "Retiring TLVs from the
            Associated Channel Header of the MPLS Generic Associated
            Channel", RFC 7026, September 2013.
 [RFC7213]  Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop
            Ethernet Addressing", RFC 7213, June 2014.

Authors' Addresses

 Dan Frost
 Blue Sun
 EMail: frost@mm.st
 Stewart Bryant
 Cisco Systems
 EMail: stbryant@cisco.com
 Matthew Bocci
 Alcatel-Lucent
 EMail: matthew.bocci@alcatel-lucent.com

Frost, et al. Standards Track [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7212.txt · Last modified: 2014/06/17 23:10 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki