[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 draft-ietf-mpls-tp-gach-dcn
Networking Working Group D. Beller
Internet-Draft Alcatel-Lucent
Intended Status: Standards Track A. Farrel
Created: March 5, 2009 Old Dog Consulting
Expires: September 5, 2009
An Inband Data Communication Network For the MPLS Transport Profile
draft-beller-mpls-tp-gach-dcn-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
A Generic Associated Channel (G-ACH) has been defined as an extension
of the pseudowire Associated Channel Header (ACH) to enable the
realization of a control/communication channel associated with
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs),
MPLS pseudowires (PWs), MPLS LSP segments, and MPLS sections between
adjacent MPLS-capable devices.
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS
architecture that identifies elements of the MPLS toolkit that may be
combined to build a carrier grade packet transport network based on
MPLS packet switching technology.
This document describes how the G-ACH may be used to provide the
infrastructure that forms part of the Management Communication
Network (MCN) and a Signaling Communication Network (SCN).
Collectively, the MCN and SCN may be referred to as the Data
Communication Network (DCN). The document explains how MCN and SCN
packets are encapsulated, carried on the G-ACH, and demultiplexed for
Beller and Farrel [Page 1]
draft-beller-mpls-tp-gach-dcn-01.txt March 2009
delivery to the management or signaling/routing components on a label
switching router (LSR).
It should be noted that the use of the G-ACH to provide connectivity
for the DCN is intended for use only where the MPLS-TP network is not
capable encapsulating or delivering native DCN messages.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC-2119 [RFC2119].
1. Introduction
The associated channel header (ACH) is specified in [RFC4385]. It is
a packet header format for use on pseudowire (PW) packets in order to
identify packets used for OAM and similar functions.
The ACH is generalized for use on any Multiprotocol Label Switching
(MPLS) Label Switching Path (LSP) in [GAL-GACH]. The generalized
concept is referred to as the Generic Associated Channel (G-ACH) and
is intended to create a control/communication channel associated with
the LSP that can be used to carry packets used for OAM and similar
functions (e.g. control plane messages).
The purpose of a packet carried on the G-ACH is indicated by the
value carried by the PW Associated Channel Type field of the G-ACH
and a registry of values is maintained by IANA.
The MPLS transport profile (MPLS-TP) is described in [MPLS-TP].
MPLS-TP is the application of MPLS to construct a packet transport
network. It constitutes a profile of MPLS that enables operational
models typical in transport networks, which includes additional OAM,
survivability and other maintenance functions not previously
supported by MPLS.
Label Switching Routers in MPLS networks may be operated using
management protocols or control plane protocols. Messaging in these
protocols is normally achieved using IP packets exchanged over IP-
capable interfaces. However, some LSRs in MPLS-TP networks may be
constructed without support for direct IP encapsulation on their
line-side interfaces and without access to an out-of-fiber data
communication network. In order that such LSRs can communicate using
management plane or control plane protocols channels must be provided
and the only available mechanism is to use an MPLS label.
Beller and Farrel [Page 2]
draft-beller-mpls-tp-gach-dcn-01.txt March 2009
The G-ACH provides a suitable mechanism, and this document defines
processes and procedures to allow the G-ACH to be used to build a
management communication network (MCN) and a signaling communication
network (SCN) together known as the data communication network (DCN)
[G.7712].
1.1. Requirements
The requirements presented in this section are based on those
communicated to the IETF by the ITU-T.
1. A packet encapsulation mechanism must be provided to support the
transport of MCN and SCN packets over the G-ACh.
2. The G-ACh carrying the MCN and SCN packets shall support the
following application scenarios:
a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when
the server layer does not provide a Management Communication
Channel (MCC) or a Signalling Communication Channel (SCC)).
b. The G-ACh is carried by a MPLS-TP tunnel that traverses another
operator's domain (carrier's carrier scenario)
3. The G-ACh shall provide two independent channels: a MCC to build
the MCN and a SCC to build the SCN. The G-ACh packet header shall
indicate whether the packet is a MCC or an SCC packet in order to
forward it to the management or control plane application for
processing.
4. The channel separation mechanism shall allow the use of separate
rate limiters and traffic shaping functions for each channel (MCC
and SCC) ensuring that the flows do not exceed their assigned
traffic profile. The rate limiter and traffic shaper are outside
the scope of the MCC and SCC definition.
5. The G-ACh that carries the MCC and SCC shall be capable of
carrying different OSI layer 3 (network layer) PDUs. These shall
include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC
packet shall indicate which layer 3 PDU is contained in the
payload field of the packet such that the packet can be forwarded
to the related layer 3 process within the management and control
plane application, respectively, for further processing.
6. The G-ACh is not required to provide specific security mechanisms.
However, the management or control plane protocols that operate
over the MCC or SCC are required to provide adequate security
mechanisms in order not to be susceptible to security attacks.
Beller and Farrel [Page 3]
draft-beller-mpls-tp-gach-dcn-01.txt March 2009
2. Procedures
Figure 1 depicts the format of an MCC/SCC packet that is sent over
the G-ACH. To send an MCC/SCC packet on the G-ACH, the MCC/SCC packet
is prepended with the extended G-ACH header. This extended G-ACH
header is composed of the G-ACH header as defined in [GAL-GACH] and
is extended by four bytes providing an 8-bit protocol identifier
(PID) field. The remaining 24 bits of the header extension are
reserved.
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 0 0 1|Version|A| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCC/SCC Packet |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MCC/SCC Packet with Associated Channel Header
o The Channel Type field determines whether the message is an MCC or
an SCC message. See Section 4 for the codepoint assignments.
o The PID field indicates the PDU type of the MCC/SCC message
The following PID values are defined:
0x00 IPv4
0x01 IPv6
0x02 OSI
0x03-0xFF Reserved
Editor Note: This approach may be changed to use the G-ACH Protocol
Identifier TLV if that work is progressed.
If the PID is OSI, the first octet of the OSI PDU header (Network
Layer Protocol Identifier) as defined in [ISO8473] indicates the
network layer PDU which can be CLNP (0x81), ES-IS (0x82), or IS-IS
(0x83) as specified in [ISO9577].
When the G-ACH sender receives an MCC message from the management
application that is supposed to be sent over the MCC, the sender
creates the extended the G-ACH header depending on the MCC layer 3
PDU, sets the Channel Type field to MCC, and prepends the MCC message
Beller and Farrel [Page 4]
draft-beller-mpls-tp-gach-dcn-01.txt March 2009
with the extended G-ACH header. The same procedure is applied when a
control plane message is supposed to be sent over the SCC. In this
case, the sender sets the Channel Type field to SCC.
If the MPLS section G-ACH is used, the GAL is added to the packet as
defined in [GAL-GACH], i.e., the TTL field SHOULD be set to 1, and
the S-bit of the GAL MUST be set to 1.
If the G-ACH is associated with an LSP, the GAL is added to the
packet and the LSP label is pushed on top of the GAL as defined in
[GAL-GACH], i.e., the TTL field of the GAL SHOULD be set to 1, and
the S-bit of the GAL MUST be set to 1.
It should be noted that the G-ACH MUST NOT be used to carry user data
and SHALL only be used to carry management or control plane messages.
Procedures that ensure this such as e.g. deep packet inspection are
outside the scope of this specification.
When a receiver has received a G-ACH packet with the G-ACH Channel
Type set to MCC or SCC, it SHALL look at the PID field of the
extended G-ACH header. If the PID value is known by the receiver it
SHALL deliver the entire packet including the MCC/SCC message to the
appropriate processing entity. If the PID value is unknown, the
receiver SHALL silently discard the received Packet and MAY increment
a counter that counts discarded packets.
It must be noted that a receiver MUST NOT forward a GAL packet based
on the GAL label as is normally the case for MPLS packets. If the GAL
appears at the bottom of the label stack, it MUST be processed as
described in the previous paragraph.
Note that there is no requirement for MPLS-TP devices to support IP
or OSI forwarding in the fast or slow paths. Thus, if a message is
received on the MCC or SCC and is not targeted to an address of the
receiving LSR, the LSR MAY discard the message as incorrectly
received.
3. Security Considerations
The G-ACH provides a virtual link between LSRs and might be used to
induce many forms of security attack. Protocols that operate over the
MCN or SCN are REQUIRED to include adequate security mechanisms and
implementations MUST allow operators to configure the use of those
mechanisms.
Beller and Farrel [Page 5]
draft-beller-mpls-tp-gach-dcn-01.txt March 2009
4. IANA Considerations
Channel Types for the Generic Associated Channel are allocated from
the IANA PW Associated Channel Type registry defined in [RFC4446] and
updated by [GAL-GACH].
IANA is requested to allocate two further Channel Types as follows:
xx Management Communication Channel (MCC)
yy Signaling Communication Channel (SCC)
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge
(PWE3) Control Word for Use over an MPLS PSN", RFC 4385,
February 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", RFC 4446, April 2006 .
[GAL-GACH] Vigoureux, M., Bocci, M., Ward, D., Swallow, G., and R.
Aggarwal, "MPLS Generic Associated Channel",
draft-ietf-mpls-tp-gach-gal, work in progress.
6. Informative References
[MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS
in Transport Networks", draft-ietf-mpls-tp-framework, work
in progress.
[G.7712] ITU-T Recommendation G.7712, "Architecture and
specification of data communication network", June 2008.
[ISO8473] ISO/IEC 8473-1, "Protocol for providing the connectionless-
mode network service: Protocol specification - Part 1:
ISO/IEC JTC 1/SC", 1998-11-01.
[ISO9577] ISO/IEC TR 9577, "Protocol identification in the network
layer ISO/IEC JTC 1/SC 6", 1999-12-15.
7. Acknowledgements
The editors wish to thank Pietro Grandi and Martin Vigoureux for
their contribution to this document.
Beller and Farrel [Page 6]
draft-beller-mpls-tp-gach-dcn-01.txt March 2009
8. Authors' Addresses
Dieter Beller
Alcatel-Lucent Germany
EMail: dieter.beller@alcatel-lucent.com
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Full Copyright Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
Beller and Farrel [Page 7]
draft-beller-mpls-tp-gach-dcn-01.txt March 2009
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Beller and Farrel [Page 8]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/