draft-ietf-mpls-gach-adv-01.txt   draft-ietf-mpls-gach-adv-02.txt 
MPLS D. Frost, Ed. MPLS D. Frost, Ed.
Internet-Draft S. Bryant, Ed. Internet-Draft S. Bryant, Ed.
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: November 24, 2012 M. Bocci, Ed. Expires: November 26, 2012 M. Bocci, Ed.
Alcatel-Lucent Alcatel-Lucent
May 23, 2012 May 25, 2012
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
draft-ietf-mpls-gach-adv-01 draft-ietf-mpls-gach-adv-02
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 November 24, 2012. This Internet-Draft will expire on November 26, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 8
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 8 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 9 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 9
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 9 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 9
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 10 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 10
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. G-ACh Advertisement Message Transmission . . . . . . . . . 11 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 11
5.2. G-ACh Advertisement Message Reception . . . . . . . . . . 11 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 11
6. Message Authentication . . . . . . . . . . . . . . . . . . . . 12 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 12
6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 12 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 12
6.2. Authentication Process . . . . . . . . . . . . . . . . . . 12 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 13
6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 13 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 13
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Associated Channel Type Allocation . . . . . . . . . . . . 15 9.1. Associated Channel Type Allocation . . . . . . . . . . . . 16
9.2. Allocation of Address Family Numbers . . . . . . . . . . . 16 9.2. Allocation of Address Family Numbers . . . . . . . . . . . 16
9.3. Creation of G-ACh Advertisement Protocol Application 9.3. Creation of G-ACh Advertisement Protocol Application
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 16 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 16 9.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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 data elements 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
information about its adjacent nodes, i.e., those nodes to which it information about its adjacent nodes, i.e., those nodes to which it
has links. At a minimum this allows a human operator or management has links. At a minimum this allows a human operator or management
application with access to the node to determine which adjacent nodes application with access to the node to determine which adjacent nodes
this node can see, which is helpful when troubleshooting connectivity this node can see, which is helpful when troubleshooting connectivity
problems. A typical example of an "adjacency awareness protocol" is problems. A typical example of an "adjacency awareness protocol" is
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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.
An important special case arises in networks based on the MPLS An important special case arises in networks based on the MPLS
Transport Profile (MPLS-TP) [RFC5921] that do not also support IP: Transport Profile (MPLS-TP) [RFC5921] that do not also support IP:
without IP, protocols for determining the Ethernet address of an without IP, protocols for determining the Ethernet address of an
adjacent MPLS node, such as the Address Resolution Protocol [RFC0826] adjacent MPLS node, such as the Address Resolution Protocol [RFC0826]
and IP version 6 Neighbor Discovery [RFC4861], are not available. and IP version 6 Neighbor Discovery [RFC4861], are not available.
The G-ACh advertisement protocol can be used to discover the Ethernet The G-ACh advertisement protocol can be used to discover the Ethernet
MAC addresses of MPLS nodes lacking IP capability MAC addresses of MPLS-TP nodes lacking IP capability
[I-D.ietf-mpls-tp-ethernet-addressing]. [I-D.ietf-mpls-tp-ethernet-addressing].
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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Overview 2. Overview
The G-ACh Advertisement Protocol has a simple one-way mode of The G-ACh Advertisement Protocol has a simple one-way mode of
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. created to identify specific applications. Application TLV objects
primarily contain static data that the receiver is meant to retain
for a period of time, but may also represent metadata or special
processing instructions.
Although one GAP message can contain data for several applications, Although one GAP message can contain data for several applications,
the receiver maintains the data associated with each application the receiver maintains the data associated with each application
separately. This enables the sender to transmit a targeted update separately. This enables the sender to transmit a targeted update
that refreshes the data for a subset of applications without that refreshes the data for a subset of applications without
affecting the data of other applications. 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-TLV1, A-TLV2, A-TLV3 Application A: A-TLV4, A-TLV15, A-TLV9
Application B: B-TLV1 Application B: B-TLV1, B-TLV3
Application C: C-TLV1, C-TLV2 Application C: C-TLV6,
where the numbers are specific Type values.
A second message might then be sent containing: A second message might then be sent containing:
Application B: B-TLV1, B-TLV2 Application B: B-TLV7, B-TLV3
Upon receiving the second message, the receiver flushes the old data Upon receiving the second message, the receiver retains B-TLV1 from
for Application B and replaces it with the new data. The data the first message and adds B-TLV7 to its B-database. How it handles
associated with Applications A and C from the first message is the new B-TLV3 depends on the rules B has specified for this object
retained. In other words, the GAP update granularity is per- type; this object could replace the old one or be combined with it in
application, not per-message or per-TLV-object. some way. The second message has no effect on the databases
maintained by the receiver for Applications A and C.
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.
skipping to change at page 7, line 24 skipping to change at page 7, line 30
~ TLV Object ~ ~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
Application Data Block Element 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. Any two ADB elements in the same ADB SHALL values for this field. The Element Length field specifies the total
have distinct Application IDs. The Element Length field specifies length in octets of this block element (including the Application ID
the total length in octets of this block element. The Lifetime field and Element Length fields). The Lifetime field specifies how long,
specifies how long, in seconds, the receiver should retain the data in seconds, the receiver should retain the data in this message.
in this message.
The remainder of the Application Data Block element consists of a The remainder of the Application Data Block element consists of a
sequence of TLV objects, which are of the form: sequence of one 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 TLV Object Format
The Type field identifies the TLV Object; an IANA registry has been The Type field identifies the TLV Object and is scoped to a specific
created to track the values for this field, which are defined on a application; each application creates an IANA registry to track its
per-application basis. The Length field specifies the length in Type values. The Length field specifies the length in octets of the
octets of the Value field. Value field.
It is permissible for the sequence of TLV objects in an ADB element
to be empty. This is useful in conjunction with setting the Lifetime
to zero in order to instruct the receiver to flush all data
associated with this application.
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. When an ADB element for the GAP is the Application ID 0x0000. These objects represent metadata and
present in a GAP message, it MUST precede other elements. processing instructions rather than static data that is meant to be
retained. When an ADB element for the GAP is present in a GAP
message, it MUST precede other elements.
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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Address Family | | Reserved | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~ ~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Address TLV Format 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 the 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 the Source Address SHOULD be included in In non-IP MPLS-TP networks a Source Address SHOULD be included in GAP
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). Length fields shown in those sections). IANA has allocated Address
Family Numbers for these identifiers; see Section 9.2.
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:
skipping to change at page 9, line 28 skipping to change at page 9, line 33
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N | | Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GAP Request TLV Format GAP Request TLV Format
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. It is a null for all applications associated with this (sender, channel) pair. It
object, i.e. its Length is set to zero. Note that data for a is a null object, i.e. its Length is set to zero.
specific application can be flushed by sending an update for the
application with the Lifetime 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.
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
skipping to change at page 11, line 4 skipping to change at page 11, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GAP Authentication TLV Format 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. G-ACh Advertisement 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.
skipping to change at page 11, line 34 skipping to change at page 11, line 34
Lifetimes SHOULD be set in such a way that at least three updates Lifetimes SHOULD be set in such a way that at least three updates
will be sent prior to Lifetime expiration. For example, if updates will be sent prior to Lifetime expiration. For example, if updates
are sent at least every 60 seconds, a Lifetime of 185 seconds may be are sent at least every 60 seconds, a Lifetime of 185 seconds may be
used. used.
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. device reset.
5.2. G-ACh Advertisement Message Reception 5.2. Message Reception
Upon receiving a G-ACh Advertisement Protocol message containing data G-ACh Advertisement Protocol message reception SHALL operate on a
for a set of applications, the receiver MUST discard any earlier data per-data-channel basis and be configurable by the operator
retained for each application in the set, and SHOULD retain the new accordingly.
data associated with each application in the set by this message for
the number of seconds specified by the Lifetime field, or until a Upon receiving a G-ACh Advertisement Protocol message that contains
newer message describing the application is received. data for some application X, the receiver determines whether it can
interpret X-data. If it cannot, then the receiver MAY retain this
data for the number of seconds specified by the Lifetime field;
although it cannot parse this data, it may still be of use to the
operator.
If the receiver can interpret X-data, then it processes the data
objects accordingly, retaining those that represent static data for
the number of seconds specified by the Lifetime field. If one of
these objects has the same Type as an object currently retained by
the receiver in its X-database, then the new object SHALL replace the
old object in the database unless the X specification dictates a
different behavior for this object type.
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 autoconfiguration, for example if
the application is an OAM protocol. The implementation SHOULD, the application is an OAM protocol. The implementation SHOULD,
however, take care to prevent cases of oscillation resulting from however, take care to prevent cases of oscillation resulting from
each endpoint attempting to adjust its configuration to match the each endpoint attempting to adjust its configuration to match the
other. Any such autoconfiguration based on GAP information MUST be other. Any such autoconfiguration based on GAP information MUST be
disabled by default. disabled by default.
6. Message Authentication 6. Message Authentication
skipping to change at page 12, line 42 skipping to change at page 13, line 7
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 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 crytographic key used by the Authentication Algorithm. the cryptographic key used by the Authentication Algorithm.
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
skipping to change at page 16, line 13 skipping to change at page 16, line 23
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) (TBD) G-ACh Advertisement Protocol No (this draft)
9.2. Allocation of Address Family Numbers 9.2. Allocation of Address Family Numbers
This document requests that IANA allocate three entries in the This document requests that IANA allocate three entries in the
Address Family Numbers registry for MPLS-TP Section, LSP, and Address Family Numbers registry for MPLS-TP Section, LSP, and
Pseudowire endpoint identifiers, based on Sections 3.5.1, 3.5.2, and Pseudowire endpoint identifiers, per Section 4.1. The allocations
3.5.3 of [RFC6428]. The allocations are: 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 9.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
skipping to change at page 17, line 35 skipping to change at page 17, line 47
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 10.2. Informative References
[I-D.ietf-mpls-tp-ethernet-addressing] [I-D.ietf-mpls-tp-ethernet-addressing]
Frost, D., Bocci, M., and S. Bryant, "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-00 (work in draft-ietf-mpls-tp-ethernet-addressing-01 (work in
progress), January 2012. progress), May 2012.
[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,
 End of changes. 35 change blocks. 
65 lines changed or deleted 78 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/