draft-ietf-mpls-gach-adv-07.txt   draft-ietf-mpls-gach-adv-08.txt 
MPLS D. Frost MPLS D. Frost
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: October 29, 2013 M. Bocci Expires: December 09, 2013 M. Bocci
Alcatel-Lucent Alcatel-Lucent
April 27, 2013 June 07, 2013
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
draft-ietf-mpls-gach-adv-07 draft-ietf-mpls-gach-adv-08
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 October 29, 2013. This Internet-Draft will expire on December 09, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. GAP Message Format . . . . . . . . . . . . . . . . . . . 7 3.1. GAP Message Format . . . . . . . . . . . . . . . . . . . 7
3.2. Applications Data Block . . . . . . . . . . . . . . . . . 7 3.2. Applications Data Block . . . . . . . . . . . . . . . . . 8
3.3. TLV Object Format . . . . . . . . . . . . . . . . . . . . 8 3.3. TLV Object Format . . . . . . . . . . . . . . . . . . . . 9
4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 9 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 9
4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . 9 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . 10
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 10 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 11
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 11 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 12
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . 11 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . 12
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . 12 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . 13
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Message Transmission . . . . . . . . . . . . . . . . . . 13 5.1. Message Transmission . . . . . . . . . . . . . . . . . . 13
5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 14 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 14
6. Message Authentication . . . . . . . . . . . . . . . . . . . 15 6. Message Authentication . . . . . . . . . . . . . . . . . . . 15
6.1. Authentication Key Identifiers . . . . . . . . . . . . . 15 6.1. Authentication Key Identifiers . . . . . . . . . . . . . 15
6.2. Authentication Process . . . . . . . . . . . . . . . . . 16 6.2. Authentication Process . . . . . . . . . . . . . . . . . 16
6.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 16 6.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 17
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 17 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 18
8. Managability Considerations . . . . . . . . . . . . . . . . . 17 8. Managability Considerations . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. Associated Channel Type Allocation . . . . . . . . . . . 18 10.1. Associated Channel Type Allocation . . . . . . . . . . . 19
10.2. Allocation of Address Family Numbers . . . . . . . . . . 18 10.2. Allocation of Address Family Numbers . . . . . . . . . . 19
10.3. Creation of G-ACh Advertisement Protocol Application 10.3. Creation of G-ACh Advertisement Protocol Application
Registry . . . . . . . . . . . . . . . . . . . . . . . . 19 Registry . . . . . . . . . . . . . . . . . . . . . . . . 19
10.4. Creation of G-ACh Advertisement Protocol TLV Registry . 19 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The MPLS Generic Associated Channel (G-ACh) is defined and described The MPLS Generic Associated Channel (G-ACh) is defined and described
in [RFC5586]. It provides an auxiliary logical data channel over in [RFC5586]. It provides an auxiliary logical data channel over
which a variety of protocols may flow. Each such data channel is which a variety of protocols may flow. Each such data channel is
associated with an MPLS Label Switched Path (LSP), a pseudowire, or a associated with an MPLS Label Switched Path (LSP), a pseudowire, or a
section (link). An important use of the G-ACh and the protocols it section (link). An important use of the G-ACh and the protocols it
supports is to provide Operations, Administration, and Maintenance supports is to provide Operations, Administration, and Maintenance
(OAM) capabilities for the associated LSP, pseudowire, or section. (OAM) [RFC6291] capabilities for the associated 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. Note in this configuration inconsistencies between endpoints. Note in this
document, an "application" refers an application of G-ACh, and should document, an "application" refers an application of G-ACh, and should
not be confused with an end-user application. not be confused with an end-user application.
The main principle guiding the design of the MPLS G-ACh Advertisement The main principle guiding the design of the MPLS G-ACh Advertisement
Protocol (GAP) is simplicity. The protocol provides a one-way method Protocol (GAP) is simplicity. The protocol provides a one-way method
of distributing information about the sender. How this information of distributing information about the sender. How this information
is used by a given receiver is a local matter. The data elements is used by a given receiver is a local matter. The data elements
distributed by the GAP are application-specific and, except for those distributed by the GAP are application-specific and, except for those
associated with the GAP itself, are outside the scope of this associated with the GAP itself, are outside the scope of this
document. An IANA registry is created to allow GAP applications to document. An IANA registry is created to allow GAP applications to
be defined as needed. be defined as needed.
Note that assigning application identifiers and associated parameters
for protocols other than the GAP itself is out of scope for this
document, and will need to be done in subsequent documents, using the
IANA considerations specified here.
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
the Link Layer Discovery Protocol [LLDP], which can provide various the Link Layer Discovery Protocol [LLDP], which can provide various
pieces of information about adjacent nodes in Ethernet networks, such pieces of information about adjacent nodes in Ethernet networks, such
skipping to change at page 6, line 13 skipping to change at page 6, line 19
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. It is the responsibility of the application and the accordingly. It is the responsibility of the application and the
network operator to ensure that the use of the GAP protocol does not network operator to ensure that the use of the GAP protocol does not
congest the link to the peer. congest the link to the peer.
Although GAP may run over a unidirectional channel, where the channel The GAP is designed to run over a unidirectional channel. However,
is bidirectional, communication may optimised through the use of a where the channel is bidirectional, communication may be optimized
number of messages defined for transmission from the receiver back to through the use of a number of messages defined for transmission from
the sender. These are optimizations and are not required for the receiver back to the sender. These are optimizations and are not
protocol operation. required for protocol operation.
3. Message Format 3. Message Format
An Associated Channel Header (ACH) Channel Type has been allocated An Associated Channel Header (ACH) Channel Type has been allocated
for the GAP as follows: for the GAP as follows:
Protocol Channel Type Protocol Channel Type
---------------------------- -------------------- ---------------------------- --------------------
G-ACh Advertisement Protocol 0xXXXX (TBD by IANA) G-ACh Advertisement Protocol 0xXXXX (TBD by IANA)
For this Channel Type, the ACH SHALL NOT be followed by the ACH TLV For this Channel Type, as noted in [I-D.ietf-mpls-retire-ach-tlv] the
Header defined in [RFC5586]. ACH SHALL NOT be followed by the ACH TLV Header defined in[RFC5586].
Fields in this document shown as Reserved or Resv are reserved for Fields in this document shown as Reserved or Resv are reserved for
future specification and MUST be set to zero. All integer values for future specification and MUST be set to zero. All integer values for
fields defined in this document SHALL be encoded in network byte fields defined in this document SHALL be encoded in network byte
order. order.
A GAP message consists of a fixed header followed by a GAP payload. A GAP message consists of a fixed header followed by a GAP payload.
The payload of a GAP message is an Application Data Block (ADB) The payload of a GAP message is an Application Data Block (ADB)
consisting of one or more block elements. Each block element consisting of one or more block elements. Each block element
contains an application identifier, a lifetime, and a series of zero contains an application identifier, a lifetime, and a series of zero
skipping to change at page 8, line 37 skipping to change at page 8, line 41
ADB. The protocol rules for the mechanism, including what ADB ADB. The protocol rules for the mechanism, including what ADB
elements are present and which TLVs are contained in an ADB elements are present and which TLVs are contained in an ADB
element, are to be defined in the document that specifies the element, are to be defined in the document that specifies the
application-specific usage. application-specific usage.
Element Length (16 bits): Specifies the total length in octets of Element Length (16 bits): Specifies the total length in octets of
this block element (including the Application ID and Element this block element (including the Application ID and Element
Length fields). Length fields).
Lifetime field (16 bits): Specifies how long, in seconds, the Lifetime field (16 bits): Specifies how long, in seconds, the
receiver should retain the data in this message (i.e. it receiver should retain the data in this message (i.e. it specifies
specifies the lifetime of the static data carried in the TLV set the lifetime of the static data carried in the TLV set of this
of this ADB). For TLVs not carrying static data, the Lifetime is ADB). For TLVs not carrying static data, the Lifetime is no
no significance. The sender of a GAP message indicates this by significance. The sender of a GAP message indicates this by
setting the Lifetime field to zero. If the Lifetime is zero, TLVs setting the Lifetime field to zero. If the Lifetime is zero, TLVs
in this ADB are processed by the receiver and the data associated in this ADB are processed by the receiver and the data associated
with these TLV types is immediately marked as expired. If the ADB with these TLV types is immediately marked as expired. If the ADB
contains no TLVs, the receiver expires all data associated TLVs contains no TLVs, the receiver expires all data associated TLVs
previously sent to this application. previously sent to this application.
The remainder of the Application Data Block element consists of a The remainder of the Application Data Block element consists of a
sequence of zero or more TLV objects which use the format defined in sequence of zero or more TLV objects which use the format defined in
Section 3.3. Section 3.3.
The scope of an ADB is an application instance attached to a specific
channel between a specific source-destination pair, and the lifetime
field specifies the lifetime of the associated ADB in that specific
context.
3.3. TLV Object Format 3.3. TLV Object Format
GAP TLV objects use the following format: GAP TLV objects use 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 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 41 skipping to change at page 10, line 8
The GAP supports several TLV objects related to its own operation via The GAP supports several TLV objects related to its own operation via
the Application ID 0x0000. These objects represent metadata and the Application ID 0x0000. These objects represent metadata and
processing instructions rather than static data that is meant to be processing instructions rather than static data that is meant to be
retained. When an ADB element for the GAP is present in a GAP retained. When an ADB element for the GAP is present in a GAP
message, it MUST precede other elements. This is particularly message, it MUST precede other elements. This is particularly
important in the case for the correct operation of the flush message. important in the case for the correct operation of the flush message.
Any application using the GAP inherits the ability to use facilities Any application using the GAP inherits the ability to use facilities
provide by Application 0x0000. provide by Application 0x0000.
Application 0x0000 GAP messages MUST be processed in the order in
which they are received.
4.1. Source Address TLV 4.1. Source Address TLV
The Source Address object identifies the sending device and possibly The Source Address object identifies the sending device and possibly
the transmitting interface and the channel; it has the following the transmitting interface and the channel; it has the following
format: format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Reserved | Length | | Type=0 | Reserved | Length |
skipping to change at page 11, line 28 skipping to change at page 11, line 37
Figure 5: GAP Request TLV Format Figure 5: GAP Request TLV Format
The intent of this TLV is to request the immediate transmission of The intent of this TLV is to request the immediate transmission of
data following a local event such as a restart rather than waiting data following a local event such as a restart rather than waiting
for a periodic update. Applications need to determine what for a periodic update. Applications need to determine what
information is meaningful to send in response to such a request. The information is meaningful to send in response to such a request. The
inclusion of an Application IDs in a Request TLV does not guarantee inclusion of an Application IDs in a Request TLV does not guarantee
that the response will provide information for that application. The that the response will provide information for that application. The
responder may also include information for applications not included responder may also include information for applications not included
in the request. in the request. A receiver SHOULD discard GAP Request messages that
arrive at a rate in excess of that which is considered reasonable for
the application.
For an application 0x0000 GAP Request it is meaningful to respond For an application 0x0000 GAP Request it is meaningful to respond
with the Source Address. with the Source Address.
It is not necessary to retain this TLV. This TLV is considered to be part of the GAP protocol and thus does
not need to be retained. The reception of the TLV may however be
recorded for management purposes.
4.3. GAP Flush TLV 4.3. GAP Flush TLV
This object is an instruction to the receiver to flush the GAP data This object is an instruction to the receiver to flush the GAP data
for all applications associated with this (sender, channel) pair. It for all applications associated with this (sender, channel) pair. It
is a null object, i.e. its Length is set to zero. is a null object, i.e. its Length is set to zero.
The GAP Flush instruction does not apply to data contained in the The GAP Flush instruction does not apply to data contained in the
message carrying the GAP Flush TLV object itself. Any application message carrying the GAP Flush TLV object itself. Any application
data contained in the same message SHALL be processed and retained by data contained in the same message SHALL be processed and retained by
the receiver as usual. the receiver as usual.
The flush TLV type is 2. The flush TLV type is 2.
It is not necessary to retain this TLV. This TLV is considered to be part of the GAP protocol and thus does
not need to be retained. The reception of the TLV may however be
recorded for management purposes.
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. Duration is a 16 bit positive integer in units of seconds. duration. Duration is a 16 bit positive integer in units of seconds.
The receiver MAY accept and act on the request, MAY ignore the The receiver MAY accept and act on the request, MAY ignore the
request, or MAY resume transmissions at any time according to request, or MAY resume transmissions at any time according to
implementation or configuration choices, and depending on local implementation or configuration choices, and depending on local
pragmatics. The format of this object is as follows: pragmatics. The format of this object is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 12, line 28 skipping to change at page 13, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application ID N-1 | Application ID N | | Application ID N-1 | Application ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: GAP Suppress TLV Format Figure 6: GAP Suppress TLV Format
If the Length is set to 2, i.e. if the list of Application IDs is If the Length is set to 2, i.e. if the list of Application IDs is
empty, then suppression of all GAP messages is requested; otherwise empty, then suppression of all GAP messages is requested; otherwise
suppression of only those updates pertaining to the listed suppression of only those updates pertaining to the listed
applications is requested. A duration of zero cancels any existing applications is requested. A duration of zero cancels any existing
suppress requests for the listed applications. suppress requests for the listed applications.
This object makes sense only for point-to-point channels or when the This object makes sense only for point-to-point channels or when the
sender is receiving unicast GAP updates. sender is receiving unicast GAP updates.
4.5. GAP Authentication TLV 4.5. GAP Authentication TLV
skipping to change at page 13, line 36 skipping to change at page 13, line 50
accordingly. accordingly.
Because GAP message transmission may be active for many logical Because GAP message transmission may be active for many logical
channels on the same physical interface, message transmission timers channels on the same physical interface, message transmission timers
SHOULD be randomized across the channels supported by a given SHOULD be randomized across the channels supported by a given
interface so as to reduce the likelihood of large synchronized interface so as to reduce the likelihood of large synchronized
message bursts. message bursts.
The Message Identifier (MI) uniquely identifies this message and its The Message Identifier (MI) uniquely identifies this message and its
value is set at the sender's discretion. It MUST NOT be assumed to value is set at the sender's discretion. It MUST NOT be assumed to
be a sequence number. be a sequence number. The scope of an MI is a channel between a
specific source-destination pair.
The Timestamp field SHALL be set to the time at which this message is The Timestamp field SHALL be set to the time at which this message is
transmitted. transmitted.
The Lifetime field of each Application Data Block element SHALL be The Lifetime field of each Application Data Block element SHALL be
set to the number of seconds the receiver is advised to retain the set to the number of seconds the receiver is advised to retain the
data associated with this message and application. data associated with this message and application.
When the transmitter wishes the data previously sent in an ADB When the transmitter wishes the data previously sent in an ADB
element to persist then it must refresh the ADB element by sending element to persist then it must refresh the ADB element by sending
skipping to change at page 14, line 42 skipping to change at page 15, line 7
objects accordingly, retaining the data associated with those that objects accordingly, retaining the data associated with those that
represent static data for the number of seconds specified by the represent static data for the number of seconds specified by the
Lifetime field. If the lifetime is zero, such data is immediately Lifetime field. If the lifetime is zero, such data is immediately
marked as expired, and if no TLVs are specified all data associated marked as expired, and if no TLVs are specified all data associated
with previously received TLVs is marked as expired Section 3. If one with previously received TLVs is marked as expired Section 3. If one
of the received TLV objects has the same Type as a previously 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 received TLV then the data from the new object SHALL replace the data
associated with that Type unless the X specification dictates a associated with that Type unless the X specification dictates a
different behavior. different behavior.
The received data is made available to local applications that
required it and are locally authorized to view it. The method for
doing this is local to the receiver and outside the scope of this
document.
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 auto-configuration, for example if message to perform some level of auto-configuration, for example if
the application is an OAM protocol. The application SHOULD, however, the application is an OAM protocol. The application SHOULD, however,
take care to prevent cases of oscillation resulting from each take care to prevent cases of oscillation resulting from each
endpoint attempting to adjust its configuration to match the other. endpoint attempting to adjust its configuration to match the other.
Any such auto-configuration based on GAP information MUST be disabled Any such auto-configuration based on GAP information MUST be disabled
by default. by default.
The MI may be used to detect and discard duplicate messages. The MI may be used to detect and discard duplicate messages.
skipping to change at page 15, line 49 skipping to change at page 16, line 19
present, the following values MAY supported: HMAC-SHA-1, HMAC- present, the following values MAY supported: HMAC-SHA-1, HMAC-
SHA-256. HMAC-SHA-1 MUST be supported. SHA-256. HMAC-SHA-1 MUST be supported.
o Authentication Keystring: A secret octet string that forms the o Authentication Keystring: A secret octet string that forms the
basis for the cryptographic key used by the Authentication basis for the cryptographic key used by the Authentication
Algorithm. It SHOULD NOT be a human memorable string. Algorithm. It SHOULD NOT be a human memorable string.
Implementations MUST be able to use random binary values of the Implementations MUST be able to use random binary values of the
appropriate length as a keystring. appropriate length as a keystring.
Implementors SHOULD consider the use of Implementors SHOULD consider the use of
[I-D.ietf-karp-crypto-key-table] for key management. [I-D.ietf-karp-crypto-key-table] for key management. If used,
authenticated information sent over the gap MUST only considered
valid if it was sent during the KARP interval between
SendLifetimeStart and SendLifeTimeEnd. However, if the GAP TLV used
to send it expires before the KARP SendLifetimeStart, then
information is never used, and if it expires before KARP
SendNotAfter, the key becomes invalid on expiry of the GAP TLV.
At the time of this writing, mechanisms for dynamic key management in At the time of this writing, mechanisms for dynamic key management in
the absence of IP are not available. Key management in such the absence of IP are not available. Key management in such
environments therefore needs to take place via the equipment environments therefore needs to take place via the equipment
management system or some other out of band service. The MPLS layer management system or some other out of band service. The MPLS layer
in a network is normally isolated from direct access by users and in a network is normally isolated from direct access by users and
thus is a relatively protected environment. Thus key turnover is a thus is a relatively protected environment. Thus key turnover is a
relatively infrequent event. relatively infrequent event.
6.2. Authentication Process 6.2. Authentication Process
The authentication process for GAP messages is straightforward. The authentication process for GAP messages is straightforward.
First, a Key ID is associated on both the sending and receiving nodes First, a Key ID is associated on both the sending and receiving nodes
with a set of authentication parameters. Following this, when the with a set of authentication parameters. Following this, when the
sender generates a GAP message, it sets the Key ID field of the GAP sender generates a GAP message, it sets the Key ID field of the GAP
Authentication TLV accordingly. (The length of the Authentication Authentication TLV accordingly. (The length of the Authentication
Data field is also known at this point, because it is a function of Data field is also known at this point, because it is a function of
the Authentication Algorithm.) The sender then computes a MAC for the Authentication Algorithm.) The sender then computes a MAC for
the message as described in Section 6.3 , and fills the the message as described in Section 6.3, and fills the Authentication
Authentication Data field of the GAP Authentication TLV with the MAC. Data field of the GAP Authentication TLV with the MAC overrighting
The message is then sent. the zeros used in computation. The message is then sent.
When the message is received, the receiver computes a MAC for it as When the message is received, the receiver computes a MAC for it as
described below. The receiver compares its computed MAC to the MAC described below, again setting the Authentication Data field of the
received in the Authentication Data field. If the two MACs are GAP Authentication TLV to all zeros before computing the MAC. The
equal, authentication of the message is considered to have succeeded; receiver compares its computed MAC to the MAC received in the
otherwise it is considered to have failed. Authentication Data field. If the two MACs are equal, authentication
of the message is considered to 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
some later time. The GAP message header contains a Timestamp field some later time. The GAP message header contains a Timestamp field
which can be used to protect against replay attacks. To achieve this which can be used to protect against replay attacks. To achieve this
protection, the receiver checks that the time recorded in the protection, the receiver checks that the time recorded in the
timestamp field of a received and authenticated GAP message timestamp field of a received and authenticated GAP message
corresponds to the current time, within a reasonable tolerance that corresponds to the current time, within a reasonable tolerance that
allows for message propagation delay, and accepts or rejects the allows for message propagation delay, and accepts or rejects the
skipping to change at page 17, line 4 skipping to change at page 17, line 29
If the clocks of the sender and receiver are not synchronized with If the clocks of the sender and receiver are not synchronized with
one another, then the receiver must perform the replay check against one another, then the receiver must perform the replay check against
its best estimate of the current time according to the sender's its best estimate of the current time according to the sender's
clock. The timestamps that appear in GAP messages can be used to clock. The timestamps that appear in GAP messages can be used to
infer the approximate clock offsets of senders and, while this does infer the approximate clock offsets of senders and, while this does
not yield high-precision clock synchronization, it suffices for not yield high-precision clock synchronization, it suffices for
purposes of the replay check with an appropriately chosen tolerance. purposes of the replay check with an appropriately chosen tolerance.
6.3. MAC Computation 6.3. MAC Computation
The HMAC proceedure described in [RFC2104] is used to compute the
MAC.
The MAC is computed over the entire GAP message as shown in Figure 1. The HMAC procedure described in [RFC2104] is used to compute the MAC.
The Authentication Data field of the GAP Authentication TLV is set to
all zeros. The MAC is then computed over the entire GAP message as
shown in Figure 1.
Where there is less data than is needed for the MAC computation, a Where there is less data than is needed for the MAC computation, a
value of zero MUST be used. value of zero MUST be used.
The length of the Authentication Data field is always less than or The length of the Authentication Data field is always less than or
equal to the message digest size of the specific hash function that equal to the message digest size of the specific hash function that
is being used, however the implementer needs to consider that is being used, however the implementer needs to consider that
although this decreases the size of the message, it results in a although this decreases the size of the message, it results in a
corresponding reduction in the strength of the assurance provided. corresponding reduction in the strength of the assurance provided.
MAC truncation is NOT RECOMMENDED. MAC truncation is NOT RECOMMENDED.
7. Link-Layer Considerations 7. Link-Layer Considerations
When the GAP is used to support device discovery on a data link, GAP When the GAP is used to support device discovery on a data link, GAP
messages must be sent in such a way that they can be received by messages must be sent in such a way that they can be received by
other listeners on the link without the sender first knowing the other listeners on the link without the sender first knowing the
link-layer addresses of the listeners. In short, they must be link-layer addresses of the listeners. In short, they must be
multicast. Considerations for multicast MPLS encapsulation are multicast. Considerations for multicast MPLS encapsulation are
discussed in [RFC5332]. For example, Section 8 of [RFC5332] discussed in [RFC5332]. For example, Section 8 of [RFC5332]
skipping to change at page 18, line 45 skipping to change at page 19, line 30
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
--------- ---------------------------- ----------- ------------ --------- ---------------------------- ----------- ------------
XXXX(TBD) G-ACh Advertisement Protocol No (this draft) XXXX(TBD) G-ACh Advertisement Protocol No (this draft)
The reader should note that the "TLV Follows" column in the registry
is in the process of being deleted [I-D.ietf-mpls-retire-ach-tlv].
10.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)
skipping to change at page 20, line 39 skipping to change at page 21, line 29
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", RFC Defect Indication for the MPLS Transport Profile", RFC
6428, November 2011. 6428, November 2011.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mpls-retire-ach-tlv]
Farrel, A. and S. Bryant, "Retiring TLVs from the
Associated Channel Header of the MPLS Generic Associated
Channel", draft-ietf-mpls-retire-ach-tlv-00 (work in
progress), May 2013.
[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", draft-ietf-mpls-tp-ethernet- Ethernet Addressing", draft-ietf-mpls-tp-ethernet-
addressing-07 (work in progress), April 2013. addressing-07 (work in progress), April 2013.
[LLDP] IEEE, , "Station and Media Access Control Connectivity [LLDP] IEEE, ., "Station and Media Access Control Connectivity
Discovery (802.1AB)", September 2009. Discovery (802.1AB)", September 2009.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
skipping to change at page 21, line 25 skipping to change at page 22, line 21
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, February 2009.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC Berger, "A Framework for MPLS in Transport Networks", RFC
5921, July 2010. 5921, July 2010.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011. Measurement for MPLS Networks", RFC 6374, September 2011.
Authors' Addresses Authors' Addresses
Dan Frost Dan Frost
Cisco Systems Cisco Systems
Email: danfrost@cisco.com Email: danfrost@cisco.com
 End of changes. 37 change blocks. 
57 lines changed or deleted 109 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/