One document matched: draft-ietf-mpls-gach-adv-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-gach-adv-06" ipr="trust200902">
<front>
<title abbrev="MPLS G-ACh Advertisement Protocol">MPLS Generic Associated
Channel (G-ACh) Advertisement Protocol</title>
<author fullname="Dan Frost" initials="D" surname="Frost">
<organization>Cisco Systems</organization>
<address>
<email>danfrost@cisco.com</email>
</address>
</author>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Matthew Bocci" initials="M" surname="Bocci">
<organization>Alcatel-Lucent</organization>
<address>
<email>matthew.bocci@alcatel-lucent.com</email>
</address>
</author>
<date year="2013" />
<area>Routing</area>
<workgroup>MPLS</workgroup>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The MPLS Generic Associated Channel (G-ACh) is defined and described
in <xref target="RFC5586"></xref>. 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. Examples of such capabilities include Pseudowire Virtual
Circuit Connectivity Verification (VCCV) <xref target="RFC5085"></xref>,
Bidirectional Forwarding Detection (BFD) for MPLS <xref
target="RFC5884"></xref>, and MPLS packet loss, delay, and throughput
measurement <xref target="RFC6374"></xref>, as well as OAM functions
developed for the MPLS Transport Profile (MPLS-TP) <xref
target="RFC5921"></xref>.</t>
<t>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.</t>
<t>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 applications to be defined as needed.</t>
<section title="Motivation">
<t>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
the Link Layer Discovery Protocol <xref target="LLDP"></xref>, 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.</t>
<t>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 can be
used to advertise information on behalf of any MPLS application.</t>
<t>In networks based on the MPLS Transport Profile (MPLS-TP) <xref
target="RFC5921"></xref> 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 <xref
target="RFC0826"></xref> and IP version 6 Neighbor Discovery <xref
target="RFC4861"></xref>, are not available. One possible use of the
G-ACh advertisement protocol is to discover the Ethernet MAC addresses
of MPLS-TP nodes lacking IP capability <xref
target="I-D.ietf-mpls-tp-ethernet-addressing"></xref>. 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.</t>
<t>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.</t>
</section>
<section title="Terminology">
<texttable align="left" style="headers">
<ttcol>Term</ttcol>
<ttcol>Definition</ttcol>
<c>G-ACh</c>
<c>Generic Associated Channel</c>
<c>GAL</c>
<c>G-ACh Label</c>
<c>GAP</c>
<c>G-ACh Advertisement Protocol</c>
<c>LSP</c>
<c>Label Switched Path</c>
<c>OAM</c>
<c>Operations, Administration, and Maintenance</c>
</texttable>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section title="Overview">
<t>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. 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.</t>
<t>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 on a
previous message.</t>
<t>For example, a GAP message might be sent containing the following
data: <list style="empty">
<t>Application A: A-TLV4, A-TLV15, A-TLV9</t>
<t>Application B: B-TLV1, B-TLV3</t>
<t>Application C: C-TLV6,</t>
</list> where the numbers are specific Type values.</t>
<t>A second message might then be sent containing: <list style="empty">
<t>Application B: B-TLV7, B-TLV3</t>
</list> 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.</t>
<t>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.</t>
<t>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.</t>
<t>Note that for bidirectional channels communication may optimised
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.</t>
</section>
<section anchor="Secmf" title="Message Format">
<t>An Associated Channel Header (ACH) Channel Type has been allocated
for the GAP as follows:</t>
<texttable align="left" style="headers">
<ttcol width="50%">Protocol</ttcol>
<ttcol>Channel Type</ttcol>
<c>G-ACh Advertisement Protocol</c>
<c>0xXXXX (TBD by IANA)</c>
</texttable>
<t>For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV
Header defined in <xref target="RFC5586"></xref>.</t>
<t>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.</t>
<t>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.</t>
<t>Malformed GAP messages MUST be discarded by the receiver, although an
error MAY be logged.</t>
<t>The following figure shows the format of a G-ACh Advertisement
Protocol message, which follows the Associated Channel Header (ACH):</t>
<figure anchor="Fig1" title="GAP Message Format">
<artwork><![CDATA[
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The meanings of the fields are: <list style="empty">
<t>Version: Protocol version, currently set to 0</t>
<t>Message Length: Size in octets of this message, i.e. of the
portion of the packet following the Associated Channel Header</t>
<t>Message Identifier (MI): Unique identifier of this message. A
sender MUST NOT re-use an MI over a given channel until the message
lifetime has expired. The sole purpose of this field is duplicate
detection in the event of a message burst (<xref
target="Txop"></xref>).</t>
<t>Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp,
as specified in Section 6 of <xref target="RFC5905"></xref></t>
</list></t>
<t>An ADB consists of one or more elements of the following format:</t>
<figure anchor="Fig2" title="Application Data Block Element">
<artwork><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
]]></artwork>
</figure>
<t>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. 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.</t>
<t>Editors note we prefer ", are to be defined in the application's
specification."</t>
<t>The Element Length field specifies the total length in octets of this
block element (including the Application ID and Element Length
fields).</t>
<t>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.</t>
<t>The remainder of the Application Data Block element consists of a
sequence of zero or more TLV objects, which are of the form:</t>
<figure anchor="Fig3" title="TLV Object Format">
<artwork><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>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. The value field need not be padded to provide alignment.</t>
<t>GAP messages do not contain a checksum. If validation of message
integrity is desired, the authentication procedures in <xref
target="auth"></xref> should be used.</t>
<t></t>
</section>
<section title="G-ACh Advertisement Protocol TLVs">
<t>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.</t>
<t>Any application using the GAP inherits the ability to use facilities
provide by Application 0x0000.</t>
<section anchor="sa-tlv" title="Source Address TLV">
<t>The Source Address object identifies the sending device and
possibly the transmitting interface and the channel; it has the
following format:</t>
<figure anchor="Fig4" title="Source Address TLV Format">
<artwork><![CDATA[
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 | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC6428"></xref> (excluding
the initial Type and Length fields shown in those sections). IANA has
allocated Address Family Numbers for these identifiers; see <xref
target="id-afn"></xref>.</t>
<t>On multipoint channels a Source Address TLV is REQUIRED.</t>
</section>
<section title="GAP Request TLV">
<t>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:</t>
<figure anchor="Fig5" title="GAP Request TLV Format">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t></t>
<t>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.</t>
<t>For an application 0x0000 GAP Request it is meaningful to respond
with the Source Address.</t>
</section>
<section title="GAP Flush TLV">
<t>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.</t>
<t>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.</t>
<t>The flush TLV type is 2.</t>
</section>
<section title="GAP Suppress TLV">
<t>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 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: <figure
anchor="Fig6" title="GAP Suppress TLV Format">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> 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.</t>
<t>This object makes sense only for point-to-point channels or when
the sender is receiving unicast GAP updates.</t>
</section>
<section title="GAP Authentication TLV">
<t>This object is used to provide authentication and integrity
validation for a GAP message. It has the following format:</t>
<figure anchor="Fig7" title="GAP Authentication TLV Format">
<artwork><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The data and procedures associated with this object are explained
in <xref target="auth"></xref>.</t>
</section>
</section>
<section title="Operation">
<section anchor="Txop" title="Message Transmission">
<t>G-ACh Advertisement Protocol message transmission SHALL operate on
a per-data-channel basis and be configurable by the operator
accordingly.</t>
<t>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.</t>
<t>The Message Identifier (MI) uniquely identifies this message and
its value is set at the sender's discretion.</t>
<t>The Timestamp field SHALL be set to the time at which this message
is transmitted.</t>
<t>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. </t>
<t>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. </t>
<t>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 <xref target="Secmf"></xref> . </t>
<t>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.</t>
</section>
<section anchor="Secmr" title="Message Reception">
<t>G-ACh Advertisement Protocol message reception SHALL operate on a
per-data-channel basis and be configurable by the operator
accordingly.</t>
<t>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.</t>
<t>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 <xref
target="Secmf"></xref>. 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. </t>
<t>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.</t>
<t>The MI may be used to detect and discard duplicate messages.</t>
</section>
</section>
<section anchor="auth" title="Message Authentication">
<t>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, 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 hash and compares the result
with the hash value in the message; if the hash values are not equal,
the message is discarded.</t>
<t>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 <xref
target="RFC5310"></xref>.</t>
<section title="Authentication Key Identifiers">
<t>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.</t>
<t>The parameters associated with a Key ID are: <list style="symbols">
<t>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.</t>
<t>Authentication Keystring: A secret string that forms the basis
for the cryptographic key used by the Authentication
Algorithm.</t>
</list>Implementors SHOULD consider the use of <xref
target="I-D.ietf-karp-crypto-key-table"></xref> for key
management.</t>
<t>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.</t>
</section>
<section title="Authentication Process">
<t>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 <xref target="hash"></xref> , and fills the
Authentication Data field of the GAP Authentication TLV with the hash
value. The message is then sent.</t>
<t>When the message is received, the receiver computes a hash for it
as described below. The receiver compares its computed value to the
hash value received in the Authentication Data field. If the two hash
values are equal, authentication of the message is considered to have
succeeded; otherwise it is considered to have failed.</t>
<t>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 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 accepts or rejects the message accordingly.
Clock corrections SHOULD be monotonic to avoid replay attack unless
operator intervention overrides this to achieve a faster convergence
with current time.</t>
<t>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.</t>
</section>
<section anchor="hash" title="Hash Computation">
<t>In the algorithm description below, the following nomenclature,
which is consistent with <xref target="FIPS-198"></xref>, is used:</t>
<texttable align="left" style="headers">
<ttcol width="20%">Symbol</ttcol>
<ttcol>Definition</ttcol>
<c>H</c>
<c>The specific hash algorithm, e.g. SHA-256</c>
<c>K</c>
<c>The Authentication Keystring</c>
<c>Ko</c>
<c>The cryptographic key used with the hash algorithm</c>
<c>B</c>
<c>The block size of H, measured in octets rather than in bits. Note
that B is the internal block size, not the hash size. This is equal
to 64 for SHA-1 and SHA-256, and to 128 for SHA-384 and SHA-512.</c>
<c>L</c>
<c>The length of the hash, measured in octets rather than in
bits</c>
<c>XOR</c>
<c>The exclusive-or operation</c>
<c>Opad</c>
<c>The hexadecimal value 0x5c repeated B times</c>
<c>Ipad</c>
<c>The hexadecimal value 0x36 repeated B times</c>
<c>Apad</c>
<c>hexadecimal value 0x878FE1F3 repeated (L/4) times</c>
</texttable>
<t><list style="numbers">
<t>Preparation of the Key <list style="empty">
<t>In this application, Ko is always L octets long.</t>
<t>If the Authentication Keystring (K) is L octets long, then
Ko is equal to K. If the Authentication Keystring (K) is more
than L octets long, then Ko is set to H(K). If the
Authentication Keystring (K) is less than L octets long, then
Ko is set to the Authentication Keystring (K) with zeros
appended to the end of the Authentication Keystring (K) such
that Ko is L octets long.</t>
</list></t>
<t>First Hash <list style="empty">
<t>First, the Authentication Data field is filled with the
value Apad.</t>
<t>Then, a first hash, also known as the inner hash, is
computed as follows: <list style="empty">
<t>First-Hash = H(Ko XOR Ipad || (GAP Message))</t>
</list></t>
<t>Here the GAP Message is the portion of the packet that
follows the Associated Channel Header.</t>
</list></t>
<t>Second Hash <list style="empty">
<t>Then a second hash, also known as the outer hash, is
computed as follows: <list style="empty">
<t>Second-Hash = H(Ko XOR Opad || First-Hash)</t>
</list></t>
</list></t>
<t>Result <list style="empty">
<t>The resulting second hash becomes the authentication data
that is sent in the Authentication Data field of the GAP
Authentication TLV. The length of the Authentication Data
field is always identical to the message digest size of the
specific hash function H that is being used.</t>
<t>This also means that the use of hash functions with larger
output sizes will increase the size of the GAP message as
transmitted on the wire.</t>
</list></t>
</list></t>
</section>
</section>
<section title="Link-Layer Considerations">
<t>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 <xref
target="RFC5332"></xref>. For example, Section 8 of <xref
target="RFC5332"></xref> describes how destination Ethernet MAC
addresses are selected for multicast MPLS packets. Since a GAP packet
transmitted over a data 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.</t>
</section>
<section title="Managability Considerations">
<t>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. The persistence of data advertised by this
protocol is applications specific, but in general SHOULD be persistent
across restarts. Received advertisements MUST be discarded across
restarts. If the received values change, the new values MUST be used and
the change made visible to the network operators.</t>
<t>All applications MUST be disabled by default and need be enabled by
the operator if required.</t>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>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 are specified in <xref target="auth"></xref>
of this document that enable receivers to ensure the authenticity and
integrity of GAP messages. These 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.</t>
</section>
<section title="IANA Considerations">
<section title="Associated Channel Type Allocation">
<t>This document requests that IANA allocate an entry in the
"Pseudowire Associated Channel Types" registry <xref
target="RFC5586"></xref> (currently located within the "Pseudowire
Name Spaces (PWE3)" registry) for the "G-ACh Advertisement Protocol",
as follows:</t>
<texttable align="left" style="headers">
<ttcol>Value</ttcol>
<ttcol>Description</ttcol>
<ttcol>TLV Follows</ttcol>
<ttcol>Reference</ttcol>
<c>XXXX(TBD)</c>
<c>G-ACh Advertisement Protocol</c>
<c>No</c>
<c>(this draft)</c>
</texttable>
</section>
<section anchor="id-afn" title="Allocation of Address Family Numbers">
<t>IANA is requested to allocate three entries from the Standards
Track range in the "Address Family Numbers" registry for MPLS-TP
Section, LSP, and Pseudowire endpoint identifiers, per <xref
target="sa-tlv"></xref>. The allocations are:</t>
<texttable align="left" style="headers">
<ttcol>Number</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>(TBD)</c>
<c>MPLS-TP Section Endpoint Identifier</c>
<c>(this draft)</c>
<c>(TBD)</c>
<c>MPLS-TP LSP Endpoint Identifier</c>
<c>(this draft)</c>
<c>(TBD)</c>
<c>MPLS-TP Pseudowire Endpoint Identifier</c>
<c>(this draft)</c>
</texttable>
</section>
<section title="Creation of G-ACh Advertisement Protocol Application Registry">
<t>This document requests that IANA create a new registry, "G-ACh
Advertisement Protocol Applications" in the "Pseudowire Name Spaces
(PWE3)" registry, with fields and initial allocations as follows:</t>
<texttable align="left" style="headers">
<ttcol>Application ID</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>0x0000</c>
<c>G-ACh Advertisement Protocol</c>
<c>(this draft)</c>
</texttable>
<t>The range of the Application ID field is 0x0000 - 0xFFFF.</t>
<t>The allocation policy for this registry is IETF Review.</t>
</section>
<section title="Creation of G-ACh Advertisement Protocol TLV Registry">
<t>This document requests that IANA create a new registry, "G-ACh
Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the
"Pseudowire Name Spaces (PWE3)" registry, with fields and initial
allocations as follows:</t>
<texttable align="left" style="headers">
<ttcol>Type Name</ttcol>
<ttcol>Type ID</ttcol>
<ttcol>Reference</ttcol>
<c>Source Address</c>
<c>0</c>
<c>(this draft)</c>
<c>GAP Request</c>
<c>1</c>
<c>(this draft)</c>
<c>GAP Flush</c>
<c>2</c>
<c>(this draft)</c>
<c>GAP Suppress</c>
<c>3</c>
<c>(this draft)</c>
<c>GAP Authentication</c>
<c>4</c>
<c>(this draft)</c>
</texttable>
<t>The range of the Type ID field is 0 - 255.</t>
<t>The allocation policy for this registry is IETF Review.</t>
</section>
</section>
<section title="Acknowledgements">
<t>We thank Adrian Farrel for his valuable review comments on this
document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.5332'?>
<?rfc include='reference.RFC.5586'?>
<?rfc include='reference.RFC.5905'?>
<?rfc include='reference.RFC.6428'?>
<reference anchor="FIPS-198">
<front>
<title>The Keyed-Hash Message Authentication Code (HMAC)</title>
<author>
<organization>US National Institute of Standards and
Technology</organization>
</author>
<date month="March" year="2002" />
</front>
<seriesInfo name="FIPS" value="PUB 198" />
</reference>
<?rfc include='reference.I-D.ietf-karp-crypto-key-table'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-mpls-tp-ethernet-addressing'?>
<?rfc include='reference.RFC.0826'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.5085'?>
<?rfc include='reference.RFC.5310'?>
<?rfc include='reference.RFC.5884'?>
<?rfc include='reference.RFC.5921'?>
<?rfc include='reference.RFC.6374'?>
<reference anchor="LLDP">
<front>
<title>Station and Media Access Control Connectivity Discovery
(802.1AB)</title>
<author surname="IEEE">
<organization abbrev="IEEE">IEEE</organization>
</author>
<date month="September" year="2009" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:09:22 |