G-ACh Registries: Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry
IANA gathers the scattered Generic Associated Channel registries into one place under the MPLS heading.
Andersson, L. and C. Pignataro, "Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry", RFC 7214, DOI 10.17487/RFC7214, May 2014, <https://www.rfc-editor.org/info/rfc7214>.
@misc{rfc7214,
series = {Request for Comments},
number = 7214,
howpublished = {RFC 7214},
publisher = {RFC Editor},
doi = {10.17487/RFC7214},
url = {https://www.rfc-editor.org/info/rfc7214},
author = {L. Andersson and C. Pignataro},
title = {{Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry}},
pagetotal = 7,
year = 2014,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) L. Andersson
Request for Comments: 7214 Huawei
Updates: 5586, 6374, 6378, 6427, 6428 C. Pignataro
Category: Standards Track Cisco
ISSN: 2070-1721 May 2014
Moving Generic Associated Channel (G-ACh) IANA Registries
to a New Registry
Abstract
RFC 5586 generalized the applicability of the pseudowire Associated
Channel Header (PW-ACH) into the Generic Associated Channel G-ACh.
However, registries and allocations of G-ACh parameters had been
distributed throughout different, sometimes unrelated, registries.
This document coalesces these into a new "Generic Associated Channel
(G-ACh) Parameters" registry under the "Multiprotocol Label Switching
Architecture (MPLS)" heading. This document updates RFC 5586.
This document also updates RFCs 6374, 6378, 6427, and 6428.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7214.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
2.1. Creation of a New Generic Associated Channel (G-ACh)
Parameters IANA Registry . . . . . . . . . . . . . . . . 3
2.2. Renaming and Moving the Pseudowire Associated Channel
Types Registry . . . . . . . . . . . . . . . . . . . . . 3
2.3. Consolidating G-ACh Registries . . . . . . . . . . . . . 4
3. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
1. Introduction
RFC 5586 generalized the PW-ACH into the G-ACh. However, registries
and allocations of G-ACh namespaces had been distributed throughout
different registries. This document coalesces these into a new
"Generic Associated Channel (G-ACh) Parameters" registry in the
"Multiprotocol Label Switching Architecture (MPLS)" name space. This
reorganization achieves two purposes: it allocates the G-ACh
registries in their natural place in the MPLS names space, and it
provides a single view of the G-ACh registries, to simplify future
assignments and avoid potential conflicts. This is an update to RFC
5586 [RFC5586].
Further, the "Pseudowire Associated Channel Types" registry is
renamed to "Generalized Associated Channel (G-ACh) Types (including
Pseudowire Associated Channel Types)" to make its generalized status
explicit, and it is moved into the newly created registry.
Additionally, RFC 6374 [RFC6374], RFC 6378 [RFC6378], RFC 6427
[RFC6427], and RFC 6428 [RFC6428] specify allocations within the
G-ACh that are now moved into the new registry.
With respect to where to find these IANA registries, the RFCs listed
above are updated as indicated in Section 3; however, the registries
themselves are not changed (with the exception of one being renamed).
They are moved unchanged to the new registry.
2. IANA Considerations
IANA has added this document as a reference for each registry that
has been moved or renamed as a result of actions requested by this
document.
IANA has replaced all the relocated registries with pointers to the
new URL or with a redirect.
2.1. Creation of a New Generic Associated Channel (G-ACh) Parameters
IANA Registry
IANA has created a new "Generic Associated Channel (G-ACh)
Parameters" registry. This is the common registry that will include
all the registries being moved in Sections 2.2 and 2.3.
2.2. Renaming and Moving the Pseudowire Associated Channel Types
Registry
This document renames the "Pseudowire Associated Channel Types"
registry [IANA-PWE3] to "MPLS Generalized Associated Channel (G-ACh)
Types (including Pseudowire Associated Channel Types)". This
registry has been moved and included in the "Generic Associated
Channel (G-ACh) Parameters" registry created in Section 2.1 because
any additional registries are dependent upon the Associated Channel
Header Type.
At the time of publishing this document and moving the registry, the
following RFCs have G-ACh Types allocated: [RFC4385], [RFC5586],
[RFC5718], [RFC5885], [RFC6374], [RFC6378], [RFC6426], [RFC6427],
[RFC6428], [RFC6435], [RFC6478], and [RFC6671].
2.3. Consolidating G-ACh Registries
This document further updates the following RFCs by moving the
registries related to G-ACh to the common "Generic Associated Channel
(G-ACh) Parameters" registry created in Section 2.1.
o From the PWE Parameters Registry [IANA-PWE3]:
* MPLS Generalized Associated Channel (G-ACh) Types [RFC5586]
* CC/CV MEP-ID TLV Registry [RFC6428]
o From the MPLS LSP Ping Parameters Registry [IANA-LSP-Ping]:
* Measurement Timestamp Type [RFC6374]
* Loss/Delay Measurement Control Code: Query Codes [RFC6374]
* Loss/Delay Measurement Control Code: Response Codes [RFC6374]
* MPLS Loss/Delay Measurement TLV Object [RFC6374]
o From the MPLS OAM Parameters Registry [IANA-MPLS-OAM]:
* MPLS Fault OAM Message Type Registry [RFC6427]
* MPLS Fault OAM Flag Registry [RFC6427]
* MPLS Fault OAM TLV Registry [RFC6427]
* MPLS PSC Request Registry [RFC6378]
* MPLS PSC TLV Registry [RFC6378]
Note that all the sub-registries in [IANA-MPLS-OAM] have been
removed from "Multiprotocol Label Switching (MPLS) Operations,
Administration, and Management (OAM) Parameters" registry.
Therefore, the IANA has removed the MPLS OAM registry, per this
document.
3. RFC Updates
This document updates [RFC5586] renaming the "Pseudowire Associated
Channel Types" [IANA-PWE3] to "MPLS Generalized Associated Channel
(G-ACh) Types (including Pseudowire Associated Channel Types)".
This document also updates the following RFCs by moving the G-ACh
related registries to a common "MPLS Generic Associated Channel
(G-ACh) Parameters" registry: RFCs 6374, 6378, 6427, and 6428.
All the registries listed above are moved without any changes to
their content. The reason to move them is to create on single place
where it is possible to find all the G-ACh parameters.
4. Security Considerations
The IANA instructions in this document do not directly introduce any
new security issues.
5. Acknowledgements
The authors want to thank Amanda Baber and Scott Bradner for review
and valuable comments.
6. References
6.1. Normative References
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011.
[RFC6427] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
and D. Ward, "MPLS Fault Management Operations,
Administration, and Maintenance (OAM)", RFC 6427, November
2011.
[RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
Connectivity Verification, Continuity Check, and Remote
Defect Indication for the MPLS Transport Profile", RFC
6428, November 2011.
6.2. Informative References
[IANA-LSP-Ping]
IANA, "Multi-Protocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters",
<http://www.iana.org/assignments/
mpls-lsp-ping-parameters>.
[IANA-MPLS-OAM]
IANA, "Multiprotocol Label Switching (MPLS) Operations,
Administration, and Management (OAM) Parameters", content
has been moved to
<http://www.iana.org/assignments/g-ach-parameters/>.
[IANA-PWE3]
IANA, "Pseudowire Name Spaces (PWE3)",
<http://www.iana.org/assignments/pwe3-parameters>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[RFC5718] Beller, D. and A. Farrel, "An In-Band Data Communication
Network For the MPLS Transport Profile", RFC 5718, January
2010.
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011.
[RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile Lock Instruct and
Loopback Functions", RFC 6435, November 2011.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", RFC 6478, May
2012.
[RFC6671] Betts, M., "Allocation of a Generic Associated Channel
Type for ITU-T MPLS Transport Profile Operation,
Maintenance, and Administration (MPLS-TP OAM)", RFC 6671,
November 2012.
Authors' Addresses
Loa Andersson
Huawei
EMail: loa@mail01.huawei.com
Carlos Pignataro
Cisco Systems, Inc.
EMail: cpignata@cisco.com
AI ELI5
On this page
§1Why the Registries Move
RFC 5586 generalized the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel (G-ACh). Registries and allocations for G-ACh namespaces had nonetheless been distributed across different registries.
RFC 7214 coalesces them into a new registry in the Multiprotocol Label Switching Architecture (MPLS) name space. The stated purposes are to place the G-ACh registries in their natural home and to give a single view that simplifies future assignments and avoids potential conflicts.
Many lists of numbers were stored in different places. The goal is to keep them together where people would look for them.
§2.1The New Parameters Registry
IANA has created a new Generic Associated Channel (G-ACh) Parameters registry. It is the common registry that holds every registry moved by the document.
Moved registries are replaced with pointers to the new URL or with a redirect, and IANA has added RFC 7214 as a reference for every registry that was moved or renamed.
There is now one big cabinet for all the related lists. The old drawers have signs that point to the cabinet.
§2.2Renaming the Associated Channel Types Registry
The "Pseudowire Associated Channel Types" registry is renamed to "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" to make its generalized status explicit. It is moved into the new parameters registry because any additional registries depend on the Associated Channel Header Type.
When it was moved, these RFCs had G-ACh Types allocated: RFC 4385, RFC 5586, RFC 5718, RFC 5885, RFC 6374, RFC 6378, RFC 6426, RFC 6427, RFC 6428, RFC 6435, RFC 6478 and RFC 6671.
The main list got a longer, clearer name so people know it covers more than just one kind of thing.
§2.3Consolidating the Related Registries
Registries are pulled from three places. From the PWE Parameters registry come the G-ACh Types and the CC/CV MEP-ID TLV registry. From the MPLS LSP Ping Parameters registry come the Measurement Timestamp Type, the Loss/Delay Measurement Control Code query codes and response codes, and the MPLS Loss/Delay Measurement TLV Object. From the MPLS OAM Parameters registry come the Fault OAM Message Type, Flag and TLV registries, and the PSC Request and PSC TLV registries.
Because all sub-registries of the MPLS OAM Parameters registry were removed, IANA has removed that registry as well.
Lists were collected from three different places and put in the new cabinet. The empty old drawer was then taken away.
| Source registry | Moved to G-ACh Parameters | Defined in |
|---|---|---|
| PWE Parameters | G-ACh Types; CC/CV MEP-ID TLV | RFC 5586; RFC 6428 |
| MPLS LSP Ping Parameters | Measurement Timestamp Type; Loss/Delay Measurement Control Codes (query, response); Loss/Delay Measurement TLV Object | RFC 6374 |
| MPLS OAM Parameters | Fault OAM Message Type, Flag and TLV; PSC Request and TLV | RFC 6427; RFC 6378 |
§3Which RFCs Are Updated
RFC 7214 updates RFC 5586 by renaming the Pseudowire Associated Channel Types registry. It also updates RFC 6374, RFC 6378, RFC 6427 and RFC 6428, because their G-ACh registries now live in the common one.
All the registries are moved without any change to their content. The only reason to move them is to create one place where all G-ACh parameters can be found.
Only the addresses of the lists changed, not what is written on them.
§4Security Considerations
The IANA instructions in this document do not directly introduce any new security issues. The registries are moved unchanged, so no values or meanings change.
Moving lists around does not make anything less safe.