draft-ietf-mpls-gach-adv-02.txt   draft-ietf-mpls-gach-adv-03.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 26, 2012 M. Bocci, Ed. Expires: April 25, 2013 M. Bocci, Ed.
Alcatel-Lucent Alcatel-Lucent
May 25, 2012 October 22, 2012
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
draft-ietf-mpls-gach-adv-02 draft-ietf-mpls-gach-adv-03
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 26, 2012. This Internet-Draft will expire on April 25, 2013.
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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 8
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 11 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 11
5.2. 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 . . . . . . . . . . . . . . . . . . 13 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 13
6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 13 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 14
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Associated Channel Type Allocation . . . . . . . . . . . . 16 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 . . 17
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 . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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
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. A primary section (link) over which a variety of protocols may flow. An
purpose of the G-ACh and the protocols it supports is to provide important use of the G-ACh and the protocols it supports is to
Operations, Administration, and Maintenance (OAM) capabilities provide Operations, Administration, and Maintenance (OAM)
associated with the underlying LSP, pseudowire, or section. Examples capabilities associated with the underlying LSP, pseudowire, or
of such capabilities include Pseudowire Virtual Circuit Connectivity section. Examples of such capabilities include Pseudowire Virtual
Verification (VCCV) [RFC5085], Bidirectional Forwarding Detection Circuit Connectivity Verification (VCCV) [RFC5085], Bidirectional
(BFD) for MPLS [RFC5884], and MPLS packet loss, delay, and throughput Forwarding Detection (BFD) for MPLS [RFC5884], and MPLS packet loss,
measurement [RFC6374], as well as OAM functions developed for the delay, and throughput measurement [RFC6374], as well as OAM functions
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
skipping to change at page 4, line 9 skipping to change at page 4, line 9
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.
An important special case arises in networks based on the MPLS In networks based on the MPLS Transport Profile (MPLS-TP) [RFC5921]
Transport Profile (MPLS-TP) [RFC5921] that do not also support IP: that do not also support IP, the normal protocols used to determine
without IP, protocols for determining the Ethernet address of an the Ethernet address of an adjacent MPLS node, such as the Address
adjacent MPLS node, such as the Address Resolution Protocol [RFC0826] Resolution Protocol [RFC0826] and IP version 6 Neighbor Discovery
and IP version 6 Neighbor Discovery [RFC4861], are not available. [RFC4861], are not available. The G-ACh advertisement protocol can
The G-ACh advertisement protocol can be used to discover the Ethernet be used to discover the Ethernet MAC addresses of MPLS-TP nodes
MAC addresses of MPLS-TP nodes lacking IP capability lacking IP capability [I-D.ietf-mpls-tp-ethernet-addressing]. Where
[I-D.ietf-mpls-tp-ethernet-addressing]. it is anticipated that the sole purpose of the GAP will be to provide
Ethernet MAC address learning, the use of LLDP SHOULD be considered.
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
skipping to change at page 6, line 22 skipping to change at page 6, line 22
G-ACh Advertisement Protocol 0xXXXX G-ACh Advertisement Protocol 0xXXXX
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.
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 7, line 33 skipping to change at page 7, line 33
. . . .
. . . .
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. 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). The Lifetime field specifies how long,
in seconds, the receiver should retain the data in this message. in seconds, the receiver should retain the data in this message. If
the lifetime is zero the data is immediately marked as expired.
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 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 ~
skipping to change at page 10, line 24 skipping to change at page 10, line 24
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N | | Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GAP Suppress TLV Format 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. applications is requested. A duration of zero cancels any existing
suppress requests for the listed applications.
This object makes sense only for point-to-point channels or when the 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
skipping to change at page 11, line 16 skipping to change at page 11, line 19
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 uniquely identifies this message and is set at The Message Identifier (MI) uniquely identifies this message and is
the sender's discretion. The Timestamp field SHALL be set to the set at the sender's discretion. The Timestamp field SHALL be set to
time at which this message is transmitted. 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 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. The MI may be used to detect and discard duplicate
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
skipping to change at page 13, line 18 skipping to change at page 13, line 22
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 below, and fills the Authentication Data the message as described in Section 6.3 , and fills the
field of the GAP Authentication TLV with the hash value. The message Authentication Data field of the GAP Authentication TLV with the hash
is then sent. value. The message is then sent.
When the message is received, the receiver computes a hash for it as When the message is received, the receiver computes a hash for it as
described below. The receiver compares its computed value to the described below. The receiver compares its computed value to the
hash value received in the Authentication Data field. If the two hash value received in the Authentication Data field. If the two
hash values are equal, authentication of the message is considered to hash values are equal, authentication of the message is considered to
have succeeded; otherwise it is considered to have failed. have succeeded; otherwise it is considered to have failed.
This process suffices to ensure the authenticity and integrity of This process suffices to ensure the authenticity and integrity of
messages, but is still vulnerable to a replay attack, in which a messages, but is still vulnerable to a replay attack, in which a
third party captures a message and sends it on to the receiver at third party captures a message and sends it on to the receiver at
skipping to change at page 13, line 47 skipping to change at page 13, line 51
message accordingly. message accordingly.
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 16, line 49 skipping to change at page 17, line 10
-------------- ---------------------------- ------------ -------------- ---------------------------- ------------
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 Specification Required. The allocation policy for this registry is Specification Required.
9.4. Creation of G-ACh Advertisement Protocol TLV Registry 9.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", with fields and initial Advertisement Protocol: GAP TLV Objects (Application ID 0)", with
allocations as follows: fields and initial 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.
skipping to change at page 17, line 46 skipping to change at page 18, line 7
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 10.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-03 (work in progress),
June 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-01 (work in draft-ietf-mpls-tp-ethernet-addressing-01 (work in
progress), May 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
 End of changes. 19 change blocks. 
36 lines changed or deleted 50 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/