draft-ietf-mpls-gach-adv-05.txt   draft-ietf-mpls-gach-adv-06.txt 
MPLS D. Frost MPLS D. Frost
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: August 9, 2013 M. Bocci Expires: August 16, 2013 M. Bocci
Alcatel-Lucent Alcatel-Lucent
February 5, 2013 February 12, 2013
MPLS Generic Associated Channel (G-ACh) Advertisement Protocol MPLS Generic Associated Channel (G-ACh) Advertisement Protocol
draft-ietf-mpls-gach-adv-05 draft-ietf-mpls-gach-adv-06
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 August 9, 2013. This Internet-Draft will expire on August 16, 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 21 skipping to change at page 2, line 21
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6
4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 8 4. G-ACh Advertisement Protocol TLVs . . . . . . . . . . . . . . 9
4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 9 4.1. Source Address TLV . . . . . . . . . . . . . . . . . . . . 9
4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 9 4.2. GAP Request TLV . . . . . . . . . . . . . . . . . . . . . 10
4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 10 4.3. GAP Flush TLV . . . . . . . . . . . . . . . . . . . . . . 10
4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 10 4.4. GAP Suppress TLV . . . . . . . . . . . . . . . . . . . . . 11
4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 11 4.5. GAP Authentication TLV . . . . . . . . . . . . . . . . . . 11
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 12 5.1. Message Transmission . . . . . . . . . . . . . . . . . . . 12
5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 12 5.2. Message Reception . . . . . . . . . . . . . . . . . . . . 13
6. Message Authentication . . . . . . . . . . . . . . . . . . . . 13 6. Message Authentication . . . . . . . . . . . . . . . . . . . . 14
6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 13 6.1. Authentication Key Identifiers . . . . . . . . . . . . . . 14
6.2. Authentication Process . . . . . . . . . . . . . . . . . . 14 6.2. Authentication Process . . . . . . . . . . . . . . . . . . 15
6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 15 6.3. Hash Computation . . . . . . . . . . . . . . . . . . . . . 15
7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 16 7. Link-Layer Considerations . . . . . . . . . . . . . . . . . . 17
8. Managability Considerations . . . . . . . . . . . . . . . . . 16 8. Managability Considerations . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. Associated Channel Type Allocation . . . . . . . . . . . . 17 10.1. Associated Channel Type Allocation . . . . . . . . . . . . 18
10.2. Allocation of Address Family Numbers . . . . . . . . . . . 18 10.2. Allocation of Address Family Numbers . . . . . . . . . . . 18
10.3. Creation of G-ACh Advertisement Protocol Application 10.3. Creation of G-ACh Advertisement Protocol Application
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 18 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 18 10.4. Creation of G-ACh Advertisement Protocol TLV Registry . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The MPLS Generic Associated Channel (G-ACh) is defined and described The MPLS Generic Associated Channel (G-ACh) is defined and described
in [RFC5586]. It provides an auxiliary logical data channel over in [RFC5586]. It provides an auxiliary logical data channel over
which a variety of protocols may flow. Each such data channel is which a variety of protocols may flow. Each such data channel is
associated with an MPLS Label Switched Path (LSP), a pseudowire, or a associated with an MPLS Label Switched Path (LSP), a pseudowire, or a
section (link). An important use of the G-ACh and the protocols it section (link). An important use of the G-ACh and the protocols it
supports is to provide Operations, Administration, and Maintenance supports is to provide Operations, Administration, and Maintenance
(OAM) capabilities for the associated LSP, pseudowire, or section. (OAM) capabilities for the associated LSP, pseudowire, or section.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
Header defined in [RFC5586]. Header defined in [RFC5586].
Fields in this document shown as Reserved or Resv are reserved for Fields in this document shown as Reserved or Resv are reserved for
future specification and MUST be set to zero. All integer values for future specification and MUST be set to zero. All integer values for
fields defined in this document SHALL be encoded in network byte fields defined in this document SHALL be encoded in network byte
order. order.
A GAP message consists of a fixed header followed by a GAP payload. A GAP message consists of a fixed header followed by a GAP payload.
The payload of a GAP message is an Application Data Block (ADB) The payload of a GAP message is an Application Data Block (ADB)
consisting of one or more block elements. Each block element consisting of one or more block elements. Each block element
contains an application identifier, a lifetime, and a series of TLV contains an application identifier, a lifetime, and a series of zero
objects for the application it describes. or more TLV objects for the application it describes.
Malformed GAP messages MUST be discarded by the receiver, although an
error MAY be logged.
The following figure shows the format of a G-ACh Advertisement The following figure shows the format of a G-ACh Advertisement
Protocol message, which follows the Associated Channel Header (ACH): Protocol message, which follows the Associated Channel Header (ACH):
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Reserved | Message Length | |Version| Reserved | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Identifier | | Message Identifier |
skipping to change at page 8, line 7 skipping to change at page 8, line 7
~ TLV Object ~ ~ TLV Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
Figure 2: Application Data Block Element Figure 2: Application Data Block Element
In this format, the Application ID identifies the application this 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. More than one block element with the same
length in octets of this block element (including the Application ID Application ID may be present in the same ADB, and block elements
and Element Length fields). with different Application IDs may also be present in the same ADB.
The protocol rules for the mechanism, including what ADB elements are
present and which TLVs are contained in an ADB element, are to be
defined in the document that specifies the application-specific
usage.
Editors note we prefer ", are to be defined in the application's
specification."
The Element Length field specifies the total length in octets of this
block element (including the Application ID and Element Length
fields).
The Lifetime field specifies how long, in seconds, the receiver The Lifetime field specifies how long, in seconds, the receiver
should retain the data in this message (i.e. it specifies the should retain the data in this message (i.e. it specifies the
lifetime of the static data carried in the TLV set of this ADB). For lifetime of the static data carried in the TLV set of this ADB). For
TLVs not carrying static data the Lifetime is of no significance. If TLVs not carrying static data the Lifetime is of no significance. If
the Lifetime is zero, TLVs in this ADB are processed by the receiver the Lifetime is zero, TLVs in this ADB are processed by the receiver
and the data associated with these TLV types is immediately marked as and the data associated with these TLV types is immediately marked as
expired. If the ADB contains no TLVs, the receiver expires all data expired. If the ADB contains no TLVs, the receiver expires all data
associated TLVs previously sent to this application. The scope of associated TLVs previously sent to this application. The scope of
the Lifetime is the source-channel-application tuple. the Lifetime is the source-channel-application tuple.
skipping to change at page 8, line 37 skipping to change at page 8, line 48
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: TLV Object Format Figure 3: TLV Object Format
The Type field identifies the TLV Object and is scoped to a specific The Type field identifies the TLV Object and is scoped to a specific
application; each application creates an IANA registry to track its application; each application creates an IANA registry to track its
Type values. The Length field specifies the length in octets of the Type values. The Length field specifies the length in octets of the
Value field. Value field. The value field need not be padded to provide
alignment.
GAP messages do not contain a checksum. If validation of message GAP messages do not contain a checksum. If validation of message
integrity is desired, the authentication procedures in Section 6 integrity is desired, the authentication procedures in Section 6
should be used. should be used.
4. G-ACh Advertisement Protocol TLVs 4. G-ACh Advertisement Protocol TLVs
The GAP supports several TLV objects related to its own operation via The GAP supports several TLV objects related to its own operation via
the Application ID 0x0000. These objects represent metadata and the Application ID 0x0000. These objects represent metadata and
processing instructions rather than static data that is meant to be processing instructions rather than static data that is meant to be
skipping to change at page 10, line 46 skipping to change at page 11, line 9
message carrying the GAP Flush TLV object itself. Any application message carrying the GAP Flush TLV object itself. Any application
data contained in the same message SHALL be processed and retained by data contained in the same message SHALL be processed and retained by
the receiver as usual. the receiver as usual.
The flush TLV type is 2. The flush TLV type is 2.
4.4. GAP Suppress TLV 4.4. GAP Suppress TLV
This object is a request to the receiver to cease sending GAP updates This object is a request to the receiver to cease sending GAP updates
to the transmitter over the current channel for the specified to the transmitter over the current channel for the specified
duration (in seconds). The request is strictly advisory: the duration (in seconds). The receiver MAY accept and act on the
receiver SHOULD accept and act on the request, but MAY override it at request, MAY ignore the request, or MAY resume transmissions at any
any time. The format of this object is as follows: time according to implementation or configuration choices, and
depending on local pragmatics. The format of this object is as
follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Reserved | Length | | Type=3 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | Application ID 1 | | Duration | Application ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
skipping to change at page 12, line 27 skipping to change at page 12, line 42
message bursts. message bursts.
The Message Identifier (MI) uniquely identifies this message and its The Message Identifier (MI) uniquely identifies this message and its
value is set at the sender's discretion. value is set at the sender's discretion.
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. Lifetimes SHOULD data associated with this message and application.
be set in such a way that at least three updates will be sent prior
to Lifetime expiration. For example, if updates are sent at least
every 60 seconds, a Lifetime of at least 210 seconds would typically
used. A sender deletes previously sent data by using the TLV
lifetime mechanism as previously described in Section 3 .
In some cases additional reliability may be desired for the delivery When the transmitter wishes the data previously sent in an ADB
of a GAP message. When this is the case, the RECOMMENDED procedure element to persist then it must refresh the ADB element by sending
is to send three instances of the message in succession, separated by another update. Refresh times SHOULD be set in such a way that at
a delay appropriate to the application. This procedure SHOULD be least three updates will be sent prior to Lifetime expiration. For
used, if at all, only for messages that are in some sense example, if the Lifetime is set to 210 seconds, then updates should
exceptional; for example when sending a flush instruction following be sent at least once every 60 seconds.
device reset.
A sender may signal that previously sent data SHOULD be marked as
expired by setting the ADB element lifetime to zero as previously
described in Section 3 .
In some cases an application may desire additional reliability for
the delivery of some of its data. When this is the case, the
transmitter MAY send several (for example three) instances of the
message in succession, separated by a delay appropriate to, or
specified by, the application. For example this procedure might be
invoked when sending a flush instruction following device reset. The
expectation is that the receiver will detect duplicate messages using
the MI.
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 14, line 21 skipping to change at page 14, line 46
algorithm to use to generate or interpret authentication data. At algorithm to use to generate or interpret authentication data. At
present, the following values are possible: HMAC-SHA-1, HMAC-SHA- present, the following values are possible: HMAC-SHA-1, HMAC-SHA-
224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. 224, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512.
o Authentication Keystring: A secret string that forms the basis for o Authentication Keystring: A secret string that forms the basis for
the cryptographic key used by the Authentication Algorithm. the cryptographic key used by the Authentication Algorithm.
Implementors SHOULD consider the use of Implementors SHOULD consider the use of
[I-D.ietf-karp-crypto-key-table] for key management. [I-D.ietf-karp-crypto-key-table] for key management.
At the time of this writing, mechanisms for dynamic key management in
the absence of IP are not available. Key management in such
environments therefore needs to take place via the equipment
management system or some other out of band service. The MPLS layer
in a network is normally isolated from direct access by users and
thus is a relatively protected environment. Thus key turnover is a
relatively infrequent event.
6.2. Authentication Process 6.2. Authentication Process
The authentication process for GAP messages is straightforward. The authentication process for GAP messages is straightforward.
First, a Key ID is associated on both the sending and receiving nodes First, a Key ID is associated on both the sending and receiving nodes
with a set of authentication parameters. Following this, when the with a set of authentication parameters. Following this, when the
sender generates a GAP message, it sets the Key ID field of the GAP sender generates a GAP message, it sets the Key ID field of the GAP
Authentication TLV accordingly. (The length of the Authentication Authentication TLV accordingly. (The length of the Authentication
Data field is also known at this point, because it is a function of Data field is also known at this point, because it is a function of
the Authentication Algorithm.) The sender then computes a hash for the Authentication Algorithm.) The sender then computes a hash for
the message as described in Section 6.3 , and fills the the message as described in Section 6.3 , and fills the
 End of changes. 19 change blocks. 
41 lines changed or deleted 73 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/