draft-ietf-mpls-gach-adv-06.txt   draft-ietf-mpls-gach-adv-07.txt 
MPLS D. Frost MPLS D. Frost
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: August 16, 2013 M. Bocci Expires: October 29, 2013 M. Bocci
Alcatel-Lucent Alcatel-Lucent
February 12, 2013 April 27, 2013
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
draft-ietf-mpls-gach-adv-06 draft-ietf-mpls-gach-adv-07
Abstract Abstract
The MPLS Generic Associated Channel (G-ACh) provides an auxiliary The MPLS Generic Associated Channel (G-ACh) provides an auxiliary
logical data channel associated with a Label Switched Path (LSP), a logical data channel associated with a Label Switched Path (LSP), a
pseudowire, or a section (link) over which a variety of protocols may pseudowire, or a section (link) over which a variety of protocols may
flow. These protocols are commonly used to provide Operations, flow. These protocols are commonly used to provide Operations,
Administration, and Maintenance (OAM) mechanisms associated with the Administration, and Maintenance (OAM) mechanisms associated with the
primary data channel. This document specifies simple procedures by primary data channel. This document specifies simple procedures by
which an endpoint of an LSP, pseudowire, or section may inform the which an endpoint of an LSP, pseudowire, or section may inform the
other endpoints of its capabilities and configuration parameters, or other endpoints of its capabilities and configuration parameters, or
other application-specific information. This information may then be other application-specific information. This information may then be
used by the receiver to validate or adjust its local configuration, used by the receiver to validate or adjust its local configuration,
and by the network operator for diagnostic purposes. and by the network operator for diagnostic purposes.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2013. This Internet-Draft will expire on October 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6
4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 9 3.1. GAP Message Format . . . . . . . . . . . . . . . . . . . 7
4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 9 3.2. Applications Data Block . . . . . . . . . . . . . . . . . 7
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 10 3.3. TLV Object Format . . . . . . . . . . . . . . . . . . . . 8
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 10 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 9
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 11 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . 9
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 11 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 10
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 12 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . 11
5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 13 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . 12
6. Message Authentication . . . . . . . . . . . . . . . . . . . . 14 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 14 5.1. Message Transmission . . . . . . . . . . . . . . . . . . 13
6.2. Authentication Process . . . . . . . . . . . . . . . . . . 15 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 14
6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 15 6. Message Authentication . . . . . . . . . . . . . . . . . . . 15
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 17 6.1. Authentication Key Identifiers . . . . . . . . . . . . . 15
8. Managability Considerations . . . . . . . . . . . . . . . . . 17 6.2. Authentication Process . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 17
10.1. Associated Channel Type Allocation . . . . . . . . . . . . 18 8. Managability Considerations . . . . . . . . . . . . . . . . . 17
10.2. Allocation of Address Family Numbers . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.3. Creation of G-ACh Advertisement Protocol Application 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Associated Channel Type Allocation . . . . . . . . . . . 18
10.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 19 10.2. Allocation of Address Family Numbers . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10.3. Creation of G-ACh Advertisement Protocol Application
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Registry . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The MPLS Generic Associated Channel (G-ACh) is defined and described The MPLS Generic Associated Channel (G-ACh) is defined and described
in [RFC5586]. It provides an auxiliary logical data channel over in [RFC5586]. It provides an auxiliary logical data channel over
which a variety of protocols may flow. Each such data channel is which a variety of protocols may flow. Each such data channel is
associated with an MPLS Label Switched Path (LSP), a pseudowire, or a 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 section (link). An important use of the G-ACh and the protocols it
supports is to provide Operations, Administration, and Maintenance supports is to provide Operations, Administration, and Maintenance
(OAM) capabilities for the associated LSP, pseudowire, or section. (OAM) capabilities for the associated LSP, pseudowire, or section.
skipping to change at page 3, line 26 skipping to change at page 3, line 26
Detection (BFD) for MPLS [RFC5884], and MPLS packet loss, delay, and Detection (BFD) for MPLS [RFC5884], and MPLS packet loss, delay, and
throughput measurement [RFC6374], as well as OAM functions developed throughput measurement [RFC6374], as well as OAM functions developed
for the MPLS Transport Profile (MPLS-TP) [RFC5921]. for the MPLS Transport Profile (MPLS-TP) [RFC5921].
This document specifies procedures for an MPLS Label Switching Router This document specifies procedures for an MPLS Label Switching Router
(LSR) to advertise its capabilities and configuration parameters, or (LSR) to advertise its capabilities and configuration parameters, or
other application-specific information, to its peers over LSPs, other application-specific information, to its peers over LSPs,
pseudowires, and sections. Receivers can then make use of this pseudowires, and sections. Receivers can then make use of this
information to validate or adjust their own configurations, and information to validate or adjust their own configurations, and
network operators can make use of it to diagnose faults and network operators can make use of it to diagnose faults and
configuration inconsistencies between endpoints. configuration inconsistencies between endpoints. Note in this
document, an "application" refers an application of G-ACh, and should
not be confused with an end-user application.
The main principle guiding the design of the MPLS G-ACh Advertisement The main principle guiding the design of the MPLS G-ACh Advertisement
Protocol (GAP) is simplicity. The protocol provides a one-way method Protocol (GAP) is simplicity. The protocol provides a one-way method
of distributing information about the sender. How this information of distributing information about the sender. How this information
is used by a given receiver is a local matter. The data elements is used by a given receiver is a local matter. The data elements
distributed by the GAP are application-specific and, except for those distributed by the GAP are application-specific and, except for those
associated with the GAP itself, are outside the scope of this associated with the GAP itself, are outside the scope of this
document. An IANA registry is created to allow GAP applications to document. An IANA registry is created to allow GAP applications to
be defined as needed. be defined as needed.
skipping to change at page 4, line 16 skipping to change at page 4, line 18
thus allows LSRs to exchange information of a similar sort to that thus allows LSRs to exchange information of a similar sort to that
supported by LLDP for Ethernet links. The GAP, however, does not 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 depend on the specific link-layer protocol in use, and can be used to
advertise information on behalf of any MPLS application. advertise information on behalf of any MPLS application.
In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921] In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921]
that do not also support IP, the normal protocols used to determine that do not also support IP, the normal protocols used to determine
the Ethernet address of an adjacent MPLS node, such as the Address the Ethernet address of an adjacent MPLS node, such as the Address
Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery
[RFC4861], are not available. One possible use of the G-ACh [RFC4861], are not available. One possible use of the G-ACh
advertisement protocol is to discover the Ethernet MAC addresses of advertisement protocol is to discover the Ethernet media access
MPLS-TP nodes lacking IP capability control addresses of MPLS-TP nodes lacking IP capability
[I-D.ietf-mpls-tp-ethernet-addressing]. However, where it is [I-D.ietf-mpls-tp-ethernet-addressing]. However, where it is
anticipated that the only data that needs to be exchanged between anticipated that the only data that needs to be exchanged between
LSRs over an Ethernet link are their Ethernet addresses, then the LSRs over an Ethernet link are their Ethernet addresses, then the
operator may instead choose to use LLDP for that purpose. operator may instead choose to use LLDP for that purpose.
The applicability of the G-ACh advertisement protocol is not limited The applicability of the G-ACh advertisement protocol is not limited
to link-layer adjacency, either in terms of message distribution or to link-layer adjacency, either in terms of message distribution or
message content. The G-ACh exists for any MPLS LSP or pseudowire, so message content. The G-ACh exists for any MPLS LSP or pseudowire, so
GAP messages can be exchanged with remote LSP or pseudowire GAP messages can be exchanged with remote LSP or pseudowire
endpoints. The content of GAP messages is extensible in a simple endpoints. The content of GAP messages is extensible in a simple
skipping to change at page 5, line 21 skipping to change at page 5, line 21
payload of a GAP message is a collection of Type-Length-Value (TLV) payload of a GAP message is a collection of Type-Length-Value (TLV)
objects, organized on a per-application basis. An IANA registry is objects, organized on a per-application basis. An IANA registry is
created to identify specific applications. Application TLV objects created to identify specific applications. Application TLV objects
primarily contain static data that the receiver is meant to retain primarily contain static data that the receiver is meant to retain
for a period of time, but may also represent metadata or special for a period of time, but may also represent metadata or special
processing instructions. processing instructions.
Each GAP message can contain data for several applications. A sender Each GAP message can contain data for several applications. A sender
may transmit a targeted update that refreshes the data for a subset may transmit a targeted update that refreshes the data for a subset
of applications without affecting the data of other applications sent of applications without affecting the data of other applications sent
on a previous message. on 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 For example, a GAP message might be sent containing the following
data: data:
Application A: A-TLV4, A-TLV15, A-TLV9 Application A: A-TLV4, A-TLV15, A-TLV9
Application B: B-TLV1, B-TLV3 Application B: B-TLV1, B-TLV3
Application C: C-TLV6, Application C: C-TLV6,
where the numbers are specific Type values. where the TLVx refers to an example GAP TLV.
A second message might then be sent containing: A second message might then be sent containing:
Application B: B-TLV7, B-TLV3 Application B: B-TLV7, B-TLV3
Upon receiving the second message, the receiver retains B-TLV1 from 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 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 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 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 some way. The second message has no effect on the databases
skipping to change at page 6, line 6 skipping to change at page 6, line 9
The rate at which GAP messages are transmitted is at the discretion The rate at which GAP messages are transmitted is at the discretion
of the sender, and may fluctuate over time as well as differ per of the sender, and may fluctuate over time as well as differ per
application. Each message contains, for each application it application. Each message contains, for each application it
describes, a lifetime that informs the receiver how long to wait describes, a lifetime that informs the receiver how long to wait
before discarding the data for that application. before discarding the data for that application.
The GAP itself provides no fragmentation and reassembly mechanisms. The GAP itself provides no fragmentation and reassembly mechanisms.
In the event that an application wishes to send larger chunks of data 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 via GAP messages than fall within the limits of packet size, it is
the responsibility of the application to fragment its data the responsibility of the application to fragment its data
accordingly. accordingly. It is the responsibility of the application and the
network operator to ensure that the use of the GAP protocol does not
congest the link to the peer.
Note that for bidirectional channels communication may optimised Although GAP may run over a unidirectional channel, where the channel
through the use of a number of messages defined for transmission from is bidirectional, communication may optimised through the use of a
the receiver back to the sender. These are optimizations and are not number of messages defined for transmission from the receiver back to
required for protocol operation. the sender. These are optimizations and are not required for
protocol operation.
3. Message Format 3. Message Format
An Associated Channel Header (ACH) Channel Type has been allocated An Associated Channel Header (ACH) Channel Type has been allocated
for the GAP as follows: for the GAP as follows:
Protocol Channel Type Protocol Channel Type
---------------------------------- -------------------- ---------------------------- --------------------
G-ACh Advertisement Protocol 0xXXXX (TBD by IANA) G-ACh Advertisement Protocol 0xXXXX (TBD by IANA)
For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV
Header defined in [RFC5586]. Header defined in [RFC5586].
Fields in this document shown as Reserved or Resv are reserved for Fields in this document shown as Reserved or Resv are reserved for
future specification and MUST be set to zero. All integer values for future specification and MUST be set to zero. All integer values for
fields defined in this document SHALL be encoded in network byte fields defined in this document SHALL be encoded in network byte
order. order.
A GAP message consists of a fixed header followed by a GAP payload. 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) The payload of a GAP message is an Application Data Block (ADB)
consisting of one or more block elements. Each block element consisting of one or more block elements. Each block element
contains an application identifier, a lifetime, and a series of zero contains an application identifier, a lifetime, and a series of zero
or more TLV objects for the application it describes. or more TLV objects for the application it describes.
Malformed GAP messages MUST be discarded by the receiver, although an Malformed GAP messages MUST be discarded by the receiver, although an
error MAY be logged. 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.
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 The following figure shows the format of a G-ACh Advertisement
Protocol message, which follows the Associated Channel Header (ACH): Protocol message, which follows the Associated Channel Header (ACH):
0 1 2 3 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 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 | |Version| Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier | | Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Application Data Block (ADB) ~ ~ Application Data Block (ADB) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: GAP Message Format Figure 1: GAP Message Format
The meanings of the fields are: The meanings of the fields are:
Version: Protocol version, currently set to 0 Version (4 bits): Protocol version. This is set to zero.
Message Length: Size in octets of this message, i.e. of the Reserved (12 bits): MUST be sent as zero.
portion of the packet following the Associated Channel Header
Message Identifier (MI): Unique identifier of this message. A Message Length (16 bits): Size in octets of this message, i.e. of
sender MUST NOT re-use an MI over a given channel until the the portion of the packet following the Associated Channel Header
message lifetime has expired. The sole purpose of this field is
duplicate detection in the event of a message burst (Section 5.1). Message Identifier (MI) (32 bits): Unique identifier of this
message. For disambiguation, a sender MUST NOT re-use an MI over
a given channel until it is confident that all ADBs associated
with 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, Timestamp: 64-bit Network Time Protocol (NTP) transmit timestamp,
as specified in Section 6 of [RFC5905] as specified in Section 6 of [RFC5905].
3.2. Applications Data Block
An ADB consists of one or more elements of the following format: An ADB consists of one or more elements of the following format:
0 1 2 3 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 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 | | Application ID | Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved | | Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~ ~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~ ~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
Figure 2: Application Data Block Element Figure 2: Application Data Block Element
In this format, the Application ID identifies the application this Application ID (16 bits) : Identifies the application this element
element describes; an IANA registry has been created to track the describes; an IANA registry has been created to track the values
values for this field. More than one block element with the same for this field. More than one block element with the same
Application ID may be present in the same ADB, and block elements Application ID may be present in the same ADB, and block elements
with different Application IDs may also be present in the same ADB. with different Application IDs may also be present in the same
The protocol rules for the mechanism, including what ADB elements are ADB. The protocol rules for the mechanism, including what ADB
present and which TLVs are contained in an ADB element, are to be elements are present and which TLVs are contained in an ADB
defined in the document that specifies the application-specific element, are to be defined in the document that specifies the
usage. 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 Element Length (16 bits): Specifies the total length in octets of
block element (including the Application ID and Element Length this block element (including the Application ID and Element
fields). Length fields).
The Lifetime field specifies how long, in seconds, the receiver Lifetime field (16 bits): Specifies how long, in seconds, the
should retain the data in this message (i.e. it specifies the receiver should retain the data in this message (i.e. it
lifetime of the static data carried in the TLV set of this ADB). For specifies the lifetime of the static data carried in the TLV set
TLVs not carrying static data the Lifetime is of no significance. If of this ADB). For TLVs not carrying static data, the Lifetime is
the Lifetime is zero, TLVs in this ADB are processed by the receiver no significance. The sender of a GAP message indicates this by
and the data associated with these TLV types is immediately marked as setting the Lifetime field to zero. If the Lifetime is zero, TLVs
expired. If the ADB contains no TLVs, the receiver expires all data in this ADB are processed by the receiver and the data associated
associated TLVs previously sent to this application. The scope of with these TLV types is immediately marked as expired. If the ADB
the Lifetime is the source-channel-application tuple. contains no TLVs, the receiver expires all data associated TLVs
previously sent to this application.
The remainder of the Application Data Block element consists of a The remainder of the Application Data Block element consists of a
sequence of zero or more TLV objects, which are of the form: sequence of zero or more TLV objects which use the format defined in
Section 3.3.
0 1 2 3 3.3. TLV Object Format
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 GAP TLV objects use the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | 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
~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: TLV Object Format Figure 3: TLV Object Format
The Type field identifies the TLV Object and is scoped to a specific Type (8 bits): Identifies the TLV Object and is scoped to a
application; each application creates an IANA registry to track its specific application; each application creates an IANA registry to
Type values. The Length field specifies the length in octets of the track its Type values.
Value field. The value field need not be padded to provide
alignment. 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 GAP messages do not contain a checksum. If validation of message
integrity is desired, the authentication procedures in Section 6 integrity is desired, the authentication procedures in Section 6
should be used. should be used.
4. G-ACh Advertisement Protocol TLVs 4. G-ACh Advertisement Protocol TLVs
The GAP supports several TLV objects related to its own operation via The GAP supports several TLV objects related to its own operation via
the Application ID 0x0000. These objects represent metadata and the Application ID 0x0000. These objects represent metadata and
processing instructions rather than static data that is meant to be processing instructions rather than static data that is meant to be
retained. When an ADB element for the GAP is present in a GAP retained. When an ADB element for the GAP is present in a GAP
message, it MUST precede other elements. message, it MUST precede other elements. This is particularly
important in the case for the correct operation of the flush message.
Any application using the GAP inherits the ability to use facilities Any application using the GAP inherits the ability to use facilities
provide by Application 0x0000. provide by Application 0x0000.
4.1. Source Address TLV 4.1. Source Address TLV
The Source Address object identifies the sending device and possibly The Source Address object identifies the sending device and possibly
the transmitting interface and the channel; it has the following the transmitting interface and the channel; it has the following
format: format:
0 1 2 3 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 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 | | Type=0 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Address Family | | Reserved (16 bits) | Address Family (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~ ~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Source Address TLV Format Figure 4: Source Address TLV Format
The Address Family field indicates the type of the address; it SHALL The Address Family field indicates the type of the address; it SHALL
be set to one of the assigned values in the IANA "Address Family be set to one of the assigned values in the IANA "Address Family
Numbers" registry. Numbers" registry.
skipping to change at page 10, line 12 skipping to change at page 10, line 40
Length fields shown in those sections). IANA has allocated Address Length fields shown in those sections). IANA has allocated Address
Family Numbers for these identifiers; see Section 10.2. Family Numbers for these identifiers; see Section 10.2.
On multipoint channels a Source Address TLV is REQUIRED. On multipoint channels a Source Address TLV is REQUIRED.
4.2. GAP Request TLV 4.2. GAP Request TLV
This object is a request by the sender for the receiver to transmit 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 an immediate unicast GAP update to the sender. If the Length field
is zero, this signifies that an update for all applications is is zero, this signifies that an update for all applications is
requested. Otherwise, the Value field specifies the applications for requested. Otherwise, the value field specifies the applications for
which an update is requested, in the form of a sequence of which an update is requested, in the form of a sequence of
Application IDs: Application IDs:
0 1 2 3 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 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 | | Type=1 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID 1 | Application ID 2 | | Application ID 1 | Application ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 35 skipping to change at page 11, line 24
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N | | Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GAP Request TLV Format Figure 5: GAP Request TLV Format
The intent of this TLV is to request the immediate transmission of The intent of this TLV is to request the immediate transmission of
data following a local event such as a restart rather than waiting data following a local event such as a restart rather than waiting
for a periodic update. Applications need to determine what for a periodic update. Applications need to determine what
information is meaningful to send in response to such a request. information is meaningful to send in response to such a request. The
inclusion of an Application IDs 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.
For an application 0x0000 GAP Request it is meaningful to respond For an application 0x0000 GAP Request it is meaningful to respond
with the Source Address. with the Source Address.
It is not necessary to retain this TLV.
4.3. GAP Flush TLV 4.3. GAP Flush TLV
This object is an instruction to the receiver to flush the GAP data This object is an instruction to the receiver to flush the GAP data
for all applications associated with this (sender, channel) pair. It for all applications associated with this (sender, channel) pair. It
is a null object, i.e. its Length is set to zero. is a null object, i.e. its Length is set to zero.
The GAP Flush instruction does not apply to data contained in the The GAP Flush instruction does not apply to data contained in the
message carrying the GAP Flush TLV object itself. Any application message carrying the GAP Flush TLV object itself. Any application
data contained in the same message SHALL be processed and retained by data contained in the same message SHALL be processed and retained by
the receiver as usual. the receiver as usual.
The flush TLV type is 2. The flush TLV type is 2.
4.4. GAP Suppress TLV It is not necessary to retain this TLV.
4.4. GAP Suppress TLV
This object is a request to the receiver to cease sending GAP updates This object is a request to the receiver to cease sending GAP updates
to the transmitter over the current channel for the specified to the transmitter over the current channel for the specified
duration (in seconds). The receiver MAY accept and act on the duration. Duration is a 16 bit positive integer in units of seconds.
request, MAY ignore the request, or MAY resume transmissions at any The receiver MAY accept and act on the request, MAY ignore the
time according to implementation or configuration choices, and request, or MAY resume transmissions at any time according to
depending on local pragmatics. The format of this object is as implementation or configuration choices, and depending on local
follows: pragmatics. The format of this object is as follows:
0 1 2 3 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 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 | | Type=3 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | Application ID 1 | | Duration | Application ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N | | Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GAP Suppress TLV Format Figure 6: GAP Suppress TLV Format
If the Length is set to 2, i.e. if the list of Application IDs is 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 empty, then suppression of all GAP messages is requested; otherwise
suppression of only those updates pertaining to the listed suppression of only those updates pertaining to the listed
applications is requested. A duration of zero cancels any existing applications is requested. A duration of zero cancels any existing
suppress requests for the listed applications. suppress requests for the listed applications.
This object makes sense only for point-to-point channels or when the This object makes sense only for point-to-point channels or when the
sender is receiving unicast GAP updates. sender is receiving unicast GAP updates.
4.5. GAP Authentication TLV 4.5. GAP Authentication TLV
This object is used to provide authentication and integrity This object is used to provide authentication and integrity
validation for a GAP message. It has the following format: validation for a GAP message. It has the following format:
0 1 2 3 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 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 | | Type=4 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Key ID | | Reserved | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GAP Authentication TLV Format Figure 7: GAP Authentication TLV Format
The data and procedures associated with this object are explained in The data and procedures associated with this object are explained in
Section 6. Section 6.
5. Operation 5. Operation
5.1. Message Transmission 5.1. Message Transmission
skipping to change at page 12, line 35 skipping to change at page 13, line 35
per-data-channel basis and be configurable by the operator per-data-channel basis and be configurable by the operator
accordingly. accordingly.
Because GAP message transmission may be active for many logical Because GAP message transmission may be active for many logical
channels on the same physical interface, message transmission timers channels on the same physical interface, message transmission timers
SHOULD be randomized across the channels supported by a given SHOULD be randomized across the channels supported by a given
interface so as to reduce the likelihood of large synchronized interface so as to reduce the likelihood of large synchronized
message bursts. message bursts.
The Message Identifier (MI) uniquely identifies this message and its The Message Identifier (MI) uniquely identifies this message and its
value is set at the sender's discretion. value is set at the sender's discretion. It MUST NOT be assumed to
be a sequence number.
The Timestamp field SHALL be set to the time at which this message is The Timestamp field SHALL be set to the time at which this message is
transmitted. transmitted.
The Lifetime field of each Application Data Block element SHALL be The Lifetime field of each Application Data Block element SHALL be
set to the number of seconds the receiver is advised to retain the set to the number of seconds the receiver is advised to retain the
data associated with this message and application. data associated with this message and application.
When the transmitter wishes the data previously sent in an ADB When the transmitter wishes the data previously sent in an ADB
element to persist then it must refresh the ADB element by sending element to persist then it must refresh the ADB element by sending
skipping to change at page 14, line 10 skipping to change at page 15, line 10
Any such auto-configuration based on GAP information MUST be disabled Any such auto-configuration based on GAP information MUST be disabled
by default. by default.
The MI may be used to detect and discard duplicate messages. The MI may be used to detect and discard duplicate messages.
6. Message Authentication 6. Message Authentication
The GAP provides a means of authenticating messages and ensuring The GAP provides a means of authenticating messages and ensuring
their integrity. This is accomplished by attaching a GAP their integrity. This is accomplished by attaching a GAP
Authentication TLV and including, in the Authentication Data field, Authentication TLV and including, in the Authentication Data field,
the output of a cryptographic hash function, the input to which is the output of a cryptographic hash function (known as a Message
the message together with a secret key known only to the sender and Authentication Code (MAC)), the input to which is the message
receiver. Upon receipt of the message, the receiver computes the together with a secret key known only to the sender and receiver.
same hash and compares the result with the hash value in the message; Upon receipt of the message, the receiver computes the same MAC and
if the hash values are not equal, the message is discarded. 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, The remainder of this section gives the details of this procedure,
which is based on the procedures for generic cryptographic which is based on the procedures for generic cryptographic
authentication for the Intermediate System to Intermediate System authentication for the Intermediate System to Intermediate System
(IS-IS) routing protocol as described in [RFC5310]. (IS-IS) routing protocol as described in [RFC5310].
6.1. Authentication Key Identifiers 6.1. Authentication Key Identifiers
An Authentication Key Identifier (Key ID) is a 16-bit tag shared by An Authentication Key Identifier (Key ID) is a 16-bit tag shared by
the sender and receiver that identifies a set of authentication the sender and receiver that identifies a set of authentication
skipping to change at page 14, line 37 skipping to change at page 15, line 39
means, such as via explicit operator configuration or a separate key- means, such as via explicit operator configuration or a separate key-
exchange protocol. Multiple Key IDs may be active on the sending and exchange protocol. Multiple Key IDs may be active on the sending and
receiving nodes simultaneously, in which case the sender locally receiving nodes simultaneously, in which case the sender locally
selects a Key ID from this set to use in an outbound message. This selects a Key ID from this set to use in an outbound message. This
capability facilitates key migration in the network. capability facilitates key migration in the network.
The parameters associated with a Key ID are: The parameters associated with a Key ID are:
o Authentication Algorithm: This signifies the authentication o Authentication Algorithm: This signifies the authentication
algorithm to use to generate or interpret authentication data. At algorithm to use to generate or interpret authentication data. At
present, the following values are possible: HMAC-SHA-1, HMAC-SHA- present, the following values MAY supported: HMAC-SHA-1, HMAC-
224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. SHA-256. HMAC-SHA-1 MUST be supported.
o Authentication Keystring: A secret string that forms the basis for o Authentication Keystring: A secret octet string that forms the
the cryptographic key used by the Authentication Algorithm. 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.
Implementors SHOULD consider the use of Implementors SHOULD consider the use of
[I-D.ietf-karp-crypto-key-table] for key management. [I-D.ietf-karp-crypto-key-table] for key management.
At the time of this writing, mechanisms for dynamic key management in At the time of this writing, mechanisms for dynamic key management in
the absence of IP are not available. Key management in such the absence of IP are not available. Key management in such
environments therefore needs to take place via the equipment environments therefore needs to take place via the equipment
management system or some other out of band service. The MPLS layer management system or some other out of band service. The MPLS layer
in a network is normally isolated from direct access by users and in a network is normally isolated from direct access by users and
thus is a relatively protected environment. Thus key turnover is a thus is a relatively protected environment. Thus key turnover is a
relatively infrequent event. relatively infrequent event.
6.2. Authentication Process 6.2. Authentication Process
The authentication process for GAP messages is straightforward. The authentication process for GAP messages is straightforward.
First, a Key ID is associated on both the sending and receiving nodes First, a Key ID is associated on both the sending and receiving nodes
with a set of authentication parameters. Following this, when the with a set of authentication parameters. Following this, when the
sender generates a GAP message, it sets the Key ID field of the GAP sender generates a GAP message, it sets the Key ID field of the GAP
Authentication TLV accordingly. (The length of the Authentication Authentication TLV accordingly. (The length of the Authentication
Data field is also known at this point, because it is a function of 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 Authentication Algorithm.) The sender then computes a MAC for
the message as described in Section 6.3 , and fills the the message as described in Section 6.3 , and fills the
Authentication Data field of the GAP Authentication TLV with the hash Authentication Data field of the GAP Authentication TLV with the MAC.
value. The message is then sent. The message is then sent.
When the message is received, the receiver computes a hash for it as When the message is received, the receiver computes a MAC for it as
described below. The receiver compares its computed value to the described below. The receiver compares its computed MAC to the MAC
hash value received in the Authentication Data field. If the two received in the Authentication Data field. If the two MACs are
hash values are equal, authentication of the message is considered to equal, authentication of the message is considered to have succeeded;
have succeeded; otherwise it is considered to have failed. otherwise it is considered to have failed.
This process suffices to ensure the authenticity and integrity of This process suffices to ensure the authenticity and integrity of
messages, but is still vulnerable to a replay attack, in which a 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 third party captures a message and sends it on to the receiver at
some later time. The GAP message header contains a Timestamp field some later time. The GAP message header contains a Timestamp field
which can be used to protect against replay attacks. To achieve this which can be used to protect against replay attacks. To achieve this
protection, the receiver checks that the time recorded in the protection, the receiver checks that the time recorded in the
timestamp field of a received and authenticated GAP message timestamp field of a received and authenticated GAP message
corresponds to the current time, within a reasonable tolerance that corresponds to the current time, within a reasonable tolerance that
allows for message propagation delay, and accepts or rejects the allows for message propagation delay, and accepts or rejects the
skipping to change at page 15, line 45 skipping to change at page 16, line 50
a faster convergence with current time. a faster convergence with current time.
If the clocks of the sender and receiver are not synchronized with If the clocks of the sender and receiver are not synchronized with
one another, then the receiver must perform the replay check against one another, then the receiver must perform the replay check against
its best estimate of the current time according to the sender's its best estimate of the current time according to the sender's
clock. The timestamps that appear in GAP messages can be used to clock. The timestamps that appear in GAP messages can be used to
infer the approximate clock offsets of senders and, while this does infer the approximate clock offsets of senders and, while this does
not yield high-precision clock synchronization, it suffices for not yield high-precision clock synchronization, it suffices for
purposes of the replay check with an appropriately chosen tolerance. purposes of the replay check with an appropriately chosen tolerance.
6.3. Hash Computation 6.3. MAC Computation
The HMAC proceedure described in [RFC2104] is used to compute the
In the algorithm description below, the following nomenclature, which MAC.
is consistent with [FIPS-198], is used:
Symbol Definition
-------------- ------------------------------------------------------
H The specific hash algorithm, e.g. SHA-256
K The Authentication Keystring
Ko The cryptographic key used with the hash algorithm
B 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.
L The length of the hash, measured in octets rather than
in bits
XOR The exclusive-or operation
Opad The hexadecimal value 0x5c repeated B times
Ipad The hexadecimal value 0x36 repeated B times
Apad hexadecimal value 0x878FE1F3 repeated (L/4) times
1. Preparation of the Key
In this application, Ko is always L octets long.
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.
2. First Hash
First, the Authentication Data field is filled with the value
Apad.
Then, a first hash, also known as the inner hash, is computed
as follows:
First-Hash = H(Ko XOR Ipad || (GAP Message))
Here the GAP Message is the portion of the packet that follows
the Associated Channel Header.
3. Second Hash
Then a second hash, also known as the outer hash, is computed
as follows:
Second-Hash = H(Ko XOR Opad || First-Hash)
4. Result
The resulting second hash becomes the authentication data that The MAC is computed over the entire GAP message as shown in Figure 1.
is sent in the Authentication Data field of the GAP Where there is less data than is needed for the MAC computation, a
Authentication TLV. The length of the Authentication Data value of zero MUST be used.
field is always identical to the message digest size of the
specific hash function H that is being used.
This also means that the use of hash functions with larger The length of the Authentication Data field is always less than or
output sizes will increase the size of the GAP message as equal to the message digest size of the specific hash function that
transmitted on the wire. is being used, however the implementer needs to consider that
although this 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 7. Link-Layer Considerations
When the GAP is used to support device discovery on a data link, GAP 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 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 other listeners on the link without the sender first knowing the
link-layer addresses of the listeners. In short, they must be link-layer addresses of the listeners. In short, they must be
multicast. Considerations for multicast MPLS encapsulation are multicast. Considerations for multicast MPLS encapsulation are
discussed in [RFC5332]. For example, Section 8 of [RFC5332] discussed in [RFC5332]. For example, Section 8 of [RFC5332]
describes how destination Ethernet MAC addresses are selected for describes how destination Ethernet MAC addresses are selected for
skipping to change at page 17, line 37 skipping to change at page 17, line 38
link contains just one label, the G-ACh Label (GAL) with label value link contains just one label, the G-ACh Label (GAL) with label value
13, the correct destination Ethernet address for frames carrying GAP 13, the correct destination Ethernet address for frames carrying GAP
packets intended for device discovery, according to these selection packets intended for device discovery, according to these selection
procedures, is 01-00-5e-80-00-0d. procedures, is 01-00-5e-80-00-0d.
8. Managability Considerations 8. Managability Considerations
The data sent and received by this protocol MUST be made accessible The data sent and received by this protocol MUST be made accessible
for inspection by network operators, and where local configuration is for inspection by network operators, and where local configuration is
updated by the received information, it MUST be clear why the updated by the received information, it MUST be clear why the
configured value has been changed. The persistence of data 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. The persistence of data
advertised by this protocol is applications specific, but in general advertised by this protocol is applications specific, but in general
SHOULD be persistent across restarts. Received advertisements MUST SHOULD be persistent across restarts. To prevent stale information
be discarded across restarts. If the received values change, the new or information from a former peer causing incorrect operation,
values MUST be used and the change made visible to the network received advertisements MUST be discarded across restarts. If the
operators. received values change, the new values MUST be used and the change
made visible to the network operators.
All applications MUST be disabled by default and need be enabled by All applications MUST be disabled by default and need be enabled by
the operator if required. the operator if required.
9. Security Considerations 9. Security Considerations
G-ACh Advertisement Protocol messages contain information about the G-ACh Advertisement Protocol messages contain information about the
sending device and its configuration, which is sent in cleartext over sending device and its configuration, which is sent in cleartext over
the wire. If an unauthorized third party gains access to the MPLS the wire. If an unauthorized third party gains access to the MPLS
data plane or the lower network layers between the sender and data plane or the lower network layers between the sender and
receiver, it can observe this information. In general, however, the receiver, it can observe this information. In general, however, the
information contained in GAP messages is no more sensitive than that information contained in GAP messages is no more sensitive than that
contained in other protocol messages, such as routing updates, which contained in other protocol messages, such as routing updates, which
are commonly sent in cleartext. No attempt is therefore made to are commonly sent in cleartext. No attempt is therefore made to
guarantee confidentiality of GAP messages. 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 which
require confidentiality will need to implement a suitable
confidentiality method.
A more significant potential threat is the transmission of GAP A more significant potential threat is the transmission of GAP
messages by unauthorized sources, or the unauthorized manipulation of messages by unauthorized sources, or the unauthorized manipulation of
messages in transit; this can disrupt the information receivers hold messages in transit; this can disrupt the information receivers hold
about legitimate senders. To protect against this threat, message about legitimate senders. To protect against this threat, message
authentication procedures are specified in Section 6 of this document authentication procedures are specified in Section 6 of this document
that enable receivers to ensure the authenticity and integrity of GAP that enable receivers to ensure the authenticity and integrity of GAP
messages. These procedures include the means to protect against messages. These procedures include the means to protect against
replay attacks, in which a third party captures a legitimate message replay attacks, in which a third party captures a legitimate message
and "replays" it to a receiver at some later time. and "replays" it to a receiver at some later time.
skipping to change at page 19, line 47 skipping to change at page 20, line 9
11. Acknowledgements 11. Acknowledgements
We thank Adrian Farrel for his valuable review comments on this We thank Adrian Farrel for his valuable review comments on this
document. document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[FIPS-198]
US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198, March 2002.
[I-D.ietf-karp-crypto-key-table] [I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang, Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", "Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-04 (work in progress), draft-ietf-karp-crypto-key-table-07 (work in progress),
October 2012. March 2013.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. Multicast Encapsulations", RFC 5332, August 2008.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
Connectivity Verification, Continuity Check, and Remote Connectivity Verification, Continuity Check, and Remote
Defect Indication for the MPLS Transport Profile", Defect Indication for the MPLS Transport Profile", RFC
RFC 6428, November 2011. 6428, November 2011.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mpls-tp-ethernet-addressing] [I-D.ietf-mpls-tp-ethernet-addressing]
Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop Frost, D., Bryant, S., and M. Bocci, "MPLS-TP Next-Hop
Ethernet Addressing", Ethernet Addressing", draft-ietf-mpls-tp-ethernet-
draft-ietf-mpls-tp-ethernet-addressing-05 (work in addressing-07 (work in progress), April 2013.
progress), February 2013.
[LLDP] IEEE, "Station and Media Access Control Connectivity [LLDP] IEEE, , "Station and Media Access Control Connectivity
Discovery (802.1AB)", September 2009. Discovery (802.1AB)", September 2009.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
skipping to change at page 21, line 14 skipping to change at page 21, line 22
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, February 2009.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", Berger, "A Framework for MPLS in Transport Networks", RFC
RFC 5921, July 2010. 5921, July 2010.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
Authors' Addresses Authors' Addresses
Dan Frost Dan Frost
Cisco Systems Cisco Systems
Email: danfrost@cisco.com Email: danfrost@cisco.com
 End of changes. 56 change blocks. 
244 lines changed or deleted 243 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/