draft-ietf-mpls-gach-adv-04.txt   draft-ietf-mpls-gach-adv-05.txt 
MPLS D. Frost, Ed. MPLS D. Frost
Internet-Draft S. Bryant, Ed. Internet-Draft S. Bryant
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: June 9, 2013 M. Bocci, Ed. Expires: August 9, 2013 M. Bocci
Alcatel-Lucent Alcatel-Lucent
December 6, 2012 February 5, 2013
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
draft-ietf-mpls-gach-adv-04 draft-ietf-mpls-gach-adv-05
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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 June 9, 2013. This Internet-Draft will expire on August 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6
4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8
4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 8 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 9
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 9 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 10
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 9 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 10
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 10 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 11
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 11 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 12
5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 11 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 12
6. Message Authentication . . . . . . . . . . . . . . . . . . . . 12 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 13
6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 12 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 13
6.2. Authentication Process . . . . . . . . . . . . . . . . . . 13 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 14
6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 14 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 15
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Managability Considerations . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Associated Channel Type Allocation . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.2. Allocation of Address Family Numbers . . . . . . . . . . . 16 10.1. Associated Channel Type Allocation . . . . . . . . . . . . 17
9.3. Creation of G-ACh Advertisement Protocol Application 10.2. Allocation of Address Family Numbers . . . . . . . . . . . 18
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.3. Creation of G-ACh Advertisement Protocol Application
9.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 17 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 in [RFC5586]. It provides an auxiliary logical data channel over
which a variety of protocols may flow. Each such data channel is
associated with an MPLS Label Switched Path (LSP), a pseudowire, or a associated with an MPLS Label Switched Path (LSP), a pseudowire, or a
section (link) over which a variety of protocols may flow. An section (link). An important use of the G-ACh and the protocols it
important use of the G-ACh and the protocols it supports is to supports is to provide Operations, Administration, and Maintenance
provide Operations, Administration, and Maintenance (OAM) (OAM) capabilities for the associated LSP, pseudowire, or section.
capabilities associated with the underlying LSP, pseudowire, or Examples of such capabilities include Pseudowire Virtual Circuit
section. Examples of such capabilities include Pseudowire Virtual Connectivity Verification (VCCV) [RFC5085], Bidirectional Forwarding
Circuit Connectivity Verification (VCCV) [RFC5085], Bidirectional Detection (BFD) for MPLS [RFC5884], and MPLS packet loss, delay, and
Forwarding Detection (BFD) for MPLS [RFC5884], and MPLS packet loss, throughput measurement [RFC6374], as well as OAM functions developed
delay, and throughput measurement [RFC6374], as well as OAM functions for the MPLS Transport Profile (MPLS-TP) [RFC5921].
developed 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.
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.
1.1. Motivation 1.1. Motivation
It is frequently useful in a network for a node to have general It is frequently useful in a network for a node to have general
skipping to change at page 4, line 7 skipping to change at page 4, line 7
pieces of information about adjacent nodes in Ethernet networks, such pieces of information about adjacent nodes in Ethernet networks, such
as system name, basic functional capabilities, link speed/duplex as system name, basic functional capabilities, link speed/duplex
settings, and maximum supported frame size. Such data is useful both settings, and maximum supported frame size. Such data is useful both
for human diagnostics and for automated detection of configuration for human diagnostics and for automated detection of configuration
inconsistencies. inconsistencies.
In MPLS networks, the G-ACh provides a convenient link-layer-agnostic In MPLS networks, the G-ACh provides a convenient link-layer-agnostic
means for communication between LSRs that are adjacent at the link means for communication between LSRs that are adjacent at the link
layer. The G-ACh advertisement protocol presented in this document layer. The G-ACh advertisement protocol presented in this document
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. 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.
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. The G-ACh advertisement protocol can [RFC4861], are not available. One possible use of the G-ACh
be used to discover the Ethernet MAC addresses of MPLS-TP nodes advertisement protocol is to discover the Ethernet MAC addresses of
lacking IP capability [I-D.ietf-mpls-tp-ethernet-addressing]. Where MPLS-TP nodes lacking IP capability
it is anticipated that the sole purpose of the GAP will be to provide [I-D.ietf-mpls-tp-ethernet-addressing]. However, where it is
Ethernet MAC address learning, the use of LLDP SHOULD be considered. anticipated that the only data that needs to be exchanged between
LSRs over an Ethernet link are their Ethernet addresses, then the
operator may instead choose to use LLDP for that purpose.
The applicability of the G-ACh advertisement protocol is not limited 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
manner, and can include any kind of information that might be useful manner, and can include any kind of information that might be useful
to MPLS LSRs connected by links, LSPs, or pseudowires. For example, to MPLS LSRs connected by links, LSPs, or pseudowires. For example,
in networks that rely on the G-ACh for OAM functions, GAP messages 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 might be used to inform adjacent LSRs of a node's OAM capabilities
and configuration parameters. and configuration parameters.
1.2. Terminology 1.2. Terminology
Term Definition Term Definition
----- ------------------------------------------- ----- -------------------------------------------
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL G-ACh Label GAL G-ACh Label
GAP G-ACh Advertisement Protocol GAP G-ACh Advertisement Protocol
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
1.3. Requirements Language 1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Overview 2. Overview
skipping to change at page 5, line 13 skipping to change at page 5, line 18
operation: a device configured to send information for a particular operation: a device configured to send information for a particular
data channel (MPLS LSP, pseudowire, or section) transmits GAP data channel (MPLS LSP, pseudowire, or section) transmits GAP
messages over the G-ACh associated with the data channel. The messages over the G-ACh associated with the data channel. The
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.
Although one GAP message can contain data for several applications, Each GAP message can contain data for several applications. A sender
the receiver maintains the data associated with each application may transmit a targeted update that refreshes the data for a subset
separately. This enables the sender to transmit a targeted update of applications without affecting the data of other applications sent
that refreshes the data for a subset of applications without on a previous message.
affecting the data of other applications.
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,
skipping to change at page 6, line 5 skipping to change at page 6, line 8
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.
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.
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 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 consits 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 TLV contains an application identifier, a lifetime, and a series of TLV
objects for the application it describes. objects for the application it describes.
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
skipping to change at page 6, line 44 skipping to change at page 7, line 18
|Version| Reserved | Message Length | |Version| Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier | | Message Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Application Data Block (ADB) ~ ~ Application Data Block (ADB) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: Protocol version, currently set to 0
Message Length: Size in octets of this message, i.e. of the Message Length: Size in octets of this message, i.e. of the
portion of the packet following the Associated Channel Header portion of the packet following the Associated Channel Header
Message Identifier: Unique identifier of this message
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 (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]
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 |
skipping to change at page 7, line 26 skipping to change at page 7, line 52
| Lifetime | Reserved | | Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~ ~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Object ~ ~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
Application Data Block Element Figure 2: Application Data Block Element
In this format, the Application ID identifies the application this In this format, the Application ID identifies the application this
element describes; an IANA registry has been created to track the element describes; an IANA registry has been created to track the
values for this field. The Element Length field specifies the total values for this field. The Element Length field specifies the total
length in octets of this block element (including the Application ID length in octets of this block element (including the Application ID
and Element Length fields). The Lifetime field specifies how long, and Element Length fields).
in seconds, the receiver should retain the data in this message. If
the lifetime is zero the data is immediately marked as expired. 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.
The remainder of the Application Data Block element consists of a The remainder of the Application Data Block element consists of a
sequence of one or more TLV objects, which are of the form: sequence of zero or more TLV objects, which are of the form:
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 | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Object Format Figure 3: TLV Object Format
The Type field identifies the TLV Object and is scoped to a specific The Type field identifies the TLV Object and is scoped to a specific
application; each application creates an IANA registry to track its application; each application creates an IANA registry to track its
Type values. The Length field specifies the length in octets of the Type values. The Length field specifies the length in octets of the
Value field. Value field.
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.
skipping to change at page 8, line 30 skipping to change at page 9, line 15
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 | Reserved | Length | | Type=0 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Address Family | | Reserved | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~ ~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
In IP networks a Source Address SHOULD be included in GAP messages In IP networks a Source Address SHOULD be included in GAP messages
and set to an IP address of the sending device; when the channel is a 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 link, this address SHOULD be an address of the transmitting
interface. interface.
In non-IP MPLS-TP networks a Source Address SHOULD be included in GAP 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 messages and set to the endpoint identifier of the channel. The
formats of these channel identifiers SHALL be as given in Sections formats of these channel identifiers SHALL be as given in Sections
3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and 3.5.1, 3.5.2, and 3.5.3 of [RFC6428] (excluding the initial Type and
Length fields shown in those sections). IANA has allocated Address Length fields shown in those sections). IANA has allocated Address
Family Numbers for these identifiers; see Section 9.2. Family Numbers for these identifiers; see Section 10.2.
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 | Reserved | Length | | Type=1 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID 1 | Application ID 2 | | Application ID 1 | Application ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N | | Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GAP Request TLV Format Figure 5: GAP Request TLV Format
The intent of this TLV is to request the immediate transmission of
data following a local event such as a restart rather than waiting
for a periodic update. Applications need to determine what
information is meaningful to send in response to such a request.
For an application 0x0000 GAP Request it is meaningful to respond
with the Source Address.
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.
4.4. GAP Suppress 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 request is strictly advisory: the duration (in seconds). The request is strictly advisory: the
receiver SHOULD accept and act on the request, but MAY override it at receiver SHOULD accept and act on the request, but MAY override it at
any time. The format of this object is as follows: any time. 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 | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | Length | | Type=4 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Key ID | | Reserved | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
G-ACh Advertisement Protocol message transmission SHALL operate on a G-ACh Advertisement Protocol message transmission SHALL operate on a
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 is The Message Identifier (MI) uniquely identifies this message and its
set at the sender's discretion. The Timestamp field SHALL be set to value is set at the sender's discretion.
the time at which this message is transmitted.
The Timestamp field SHALL be set to the time at which this message is
transmitted.
The Lifetime field of each Application Data Block element SHALL be 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. Lifetimes SHOULD
be set in such a way that at least three updates will be sent prior
Lifetimes SHOULD be set in such a way that at least three updates to Lifetime expiration. For example, if updates are sent at least
will be sent prior to Lifetime expiration. For example, if updates every 60 seconds, a Lifetime of at least 210 seconds would typically
are sent at least every 60 seconds, a Lifetime of 185 seconds may be used. A sender deletes previously sent data by using the TLV
used. lifetime mechanism as previously described in Section 3 .
In some cases additional reliability may be desired for the delivery In some cases additional reliability may be desired for the delivery
of a GAP message. When this is the case, the RECOMMENDED procedure of a GAP message. When this is the case, the RECOMMENDED procedure
is to send three instances of the message in succession, separated by is to send three instances of the message in succession, separated by
a delay appropriate to the application. This procedure SHOULD be a delay appropriate to the application. This procedure SHOULD be
used, if at all, only for messages that are in some sense used, if at all, only for messages that are in some sense
exceptional; for example when sending a flush instruction following exceptional; for example when sending a flush instruction following
device reset. The MI may be used to detect and discard duplicate device reset.
messages.
5.2. Message Reception 5.2. Message Reception
G-ACh Advertisement Protocol message reception SHALL operate on a G-ACh Advertisement Protocol message reception SHALL operate on a
per-data-channel basis and be configurable by the operator per-data-channel basis and be configurable by the operator
accordingly. accordingly.
Upon receiving a G-ACh Advertisement Protocol message that contains Upon receiving a G-ACh Advertisement Protocol message that contains
data for some application X, the receiver determines whether it can data for some application X, the receiver determines whether it can
interpret X-data. If it cannot, then the receiver MAY retain this interpret X-data. If it cannot, then the receiver MAY retain this
data for the number of seconds specified by the Lifetime field; 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 although it cannot parse this data, it may still be of use to the
operator. operator.
If the receiver can interpret X-data, then it processes the data If the receiver can interpret X-data, then it processes the data
objects accordingly, retaining those that represent static data for objects accordingly, retaining the data associated with those that
the number of seconds specified by the Lifetime field. If one of represent static data for the number of seconds specified by the
these objects has the same Type as an object currently retained by Lifetime field. If the lifetime is zero, such data is immediately
the receiver in its X-database, then the new object SHALL replace the marked as expired, and if no TLVs are specified all data associated
old object in the database unless the X specification dictates a with previously received TLVs is marked as expired Section 3. If one
different behavior for this object type. of the received TLV objects has the same Type as a previously
received TLV then the data from the new object SHALL replace the data
associated with that Type unless the X specification dictates a
different behavior.
The receiver MAY make use of the application data contained in a GAP The receiver MAY make use of the application data contained in a GAP
message to perform some level of autoconfiguration, for example if message to perform some level of auto-configuration, for example if
the application is an OAM protocol. The implementation SHOULD, the application is an OAM protocol. The application SHOULD, however,
however, take care to prevent cases of oscillation resulting from take care to prevent cases of oscillation resulting from each
each endpoint attempting to adjust its configuration to match the endpoint attempting to adjust its configuration to match the other.
other. Any such autoconfiguration based on GAP information MUST be Any such auto-configuration based on GAP information MUST be disabled
disabled by default. by default.
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, the input to which is
the message together with a secret key known only to the sender and the message together with a secret key known only to the sender and
receiver. Upon receipt of the message, the receiver computes the receiver. Upon receipt of the message, the receiver computes the
same hash and compares the result with the hash value in the message; same hash and compares the result with the hash value in the message;
skipping to change at page 13, line 13 skipping to change at page 14, line 18
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 are possible: HMAC-SHA-1, HMAC-SHA-
224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. 224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512.
o Authentication Keystring: A secret string that forms the basis for o Authentication Keystring: A secret string that forms the basis for
the cryptographic key used by the Authentication Algorithm. the cryptographic key used by the Authentication Algorithm.
Implementors SHOULD consider the use of
[I-D.ietf-karp-crypto-key-table] for key management.
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 hash for
the message as described in Section 6.3 , and fills the the message as described in Section 6.3 , and fills the
skipping to change at page 13, line 41 skipping to change at page 14, line 49
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
message accordingly. message accordingly. Clock corrections SHOULD be monotonic to avoid
replay attack unless operator intervention overrides this to achieve
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.
Implementors SHOULD consider the use of
[I-D.ietf-karp-crypto-key-table] for key management.
6.3. Hash Computation 6.3. Hash Computation
In the algorithm description below, the following nomenclature, which In the algorithm description below, the following nomenclature, which
is consistent with [FIPS-198], is used: is consistent with [FIPS-198], is used:
Symbol Definition Symbol Definition
-------------- ------------------------------------------------------ -------------- ------------------------------------------------------
H The specific hash algorithm, e.g. SHA-256 H The specific hash algorithm, e.g. SHA-256
K The Authentication Keystring K The Authentication Keystring
Ko The cryptographic key used with the hash algorithm Ko The cryptographic key used with the hash algorithm
skipping to change at page 15, line 39 skipping to change at page 16, line 44
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
multicast MPLS packets. Since a GAP packet transmitted over a data multicast MPLS packets. Since a GAP packet transmitted over a data
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. Security Considerations 8. Managability Considerations
The data sent and received by this protocol MUST be made accessible
for inspection by network operators, and where local configuration is
updated by the received information, it MUST be clear why the
configured value has been changed. 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.
All applications MUST be disabled by default and need be enabled by
the operator if required.
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.
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 this document that enable authentication procedures are specified in Section 6 of this document
receivers to ensure the authenticity and integrity of GAP messages. that enable receivers to ensure the authenticity and integrity of GAP
These procedures include the means to protect against replay attacks, messages. These procedures include the means to protect against
in which a third party captures a legitimate message and "replays" it replay attacks, in which a third party captures a legitimate message
to a receiver at some later time. and "replays" it to a receiver at some later time.
9. IANA Considerations 10. IANA Considerations
9.1. Associated Channel Type Allocation 10.1. Associated Channel Type Allocation
This document requests that IANA allocate an entry in the "Pseudowire This document requests that IANA allocate an entry in the "Pseudowire
Associated Channel Types" registry [RFC5586] (currently located Associated Channel Types" registry [RFC5586] (currently located
within the "Pseudowire Name Spaces (PWE3)" registry) for the "G-ACh within the "Pseudowire Name Spaces (PWE3)" registry) for the "G-ACh
Advertisement Protocol", as follows: Advertisement Protocol", as follows:
Value Description TLV Follows Reference Value Description TLV Follows Reference
----- ---------------------------- ----------- ------------ --------- ---------------------------- ----------- ------------
(TBD) G-ACh Advertisement Protocol No (this draft) XXXX(TBD) G-ACh Advertisement Protocol No (this draft)
9.2. Allocation of Address Family Numbers 10.2. Allocation of Address Family Numbers
IANA is requested to allocate three entries from the Standards Track IANA is requested to allocate three entries from the Standards Track
range in the "Address Family Numbers" registry for MPLS-TP Section, range in the "Address Family Numbers" registry for MPLS-TP Section,
LSP, and Pseudowire endpoint identifiers, per Section 4.1. The LSP, and Pseudowire endpoint identifiers, per Section 4.1. The
allocations are: allocations are:
Number Description Reference Number Description Reference
------ -------------------------------------- ------------ ------ -------------------------------------- ------------
(TBD) MPLS-TP Section Endpoint Identifier (this draft) (TBD) MPLS-TP Section Endpoint Identifier (this draft)
(TBD) MPLS-TP LSP Endpoint Identifier (this draft) (TBD) MPLS-TP LSP Endpoint Identifier (this draft)
(TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft) (TBD) MPLS-TP Pseudowire Endpoint Identifier (this draft)
9.3. Creation of G-ACh Advertisement Protocol Application Registry 10.3. Creation of G-ACh Advertisement Protocol Application Registry
This document requests that IANA create a new registry, "G-ACh This document requests that IANA create a new registry, "G-ACh
Advertisement Protocol Applications" in the "Pseudowire Name Spaces Advertisement Protocol Applications" in the "Pseudowire Name Spaces
(PWE3)" registry, with fields and initial allocations as follows: (PWE3)" registry, with fields and initial allocations as follows:
Application ID Description Reference Application ID Description Reference
-------------- ---------------------------- ------------ -------------- ---------------------------- ------------
0x0000 G-ACh Advertisement Protocol (this draft) 0x0000 G-ACh Advertisement Protocol (this draft)
The range of the Application ID field is 0x0000 - 0xFFFF. The range of the Application ID field is 0x0000 - 0xFFFF.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
9.4. Creation of G-ACh Advertisement Protocol TLV Registry 10.4. Creation of G-ACh Advertisement Protocol TLV Registry
This document requests that IANA create a new registry, "G-ACh This document requests that IANA create a new registry, "G-ACh
Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the Advertisement Protocol: GAP TLV Objects (Application ID 0)" in the
"Pseudowire Name Spaces (PWE3)" registry, with fields and initial "Pseudowire Name Spaces (PWE3)" registry, with fields and initial
allocations as follows: allocations as follows:
Type Name Type ID Reference Type Name Type ID Reference
------------------ ------- ------------ ------------------ ------- ------------
Source Address 0 (this draft) Source Address 0 (this draft)
GAP Request 1 (this draft) GAP Request 1 (this draft)
GAP Flush 2 (this draft) GAP Flush 2 (this draft)
GAP Suppress 3 (this draft) GAP Suppress 3 (this draft)
GAP Authentication 4 (this draft) GAP Authentication 4 (this draft)
The range of the Type ID field is 0 - 255. The range of the Type ID field is 0 - 255.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
10. References 11. Acknowledgements
10.1. Normative References We thank Adrian Farrel for his valuable review comments on this
document.
12. References
12.1. Normative References
[FIPS-198] [FIPS-198]
US National Institute of Standards and Technology, "The US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198, March 2002. 198, March 2002.
[I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-04 (work in progress),
October 2012.
[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 6428, November 2011. RFC 6428, November 2011.
10.2. Informative References 12.2. Informative References
[I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-04 (work in progress),
October 2012.
[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-addressing-02 (work in draft-ietf-mpls-tp-ethernet-addressing-05 (work in
progress), November 2012. 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,
skipping to change at page 19, line 7 skipping to change at page 20, line 36
[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 5921, July 2010. RFC 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 (editor) Dan Frost
Cisco Systems Cisco Systems
Email: danfrost@cisco.com Email: danfrost@cisco.com
Stewart Bryant (editor) Stewart Bryant
Cisco Systems Cisco Systems
Email: stbryant@cisco.com Email: stbryant@cisco.com
Matthew Bocci
Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Email: matthew.bocci@alcatel-lucent.com Email: matthew.bocci@alcatel-lucent.com
 End of changes. 59 change blocks. 
131 lines changed or deleted 191 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/