draft-ietf-mpls-tp-gach-dcn-05.txt   draft-ietf-mpls-tp-gach-dcn-06.txt 
Networking Working Group D. Beller Networking Working Group D. Beller
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended Status: Standards Track A. Farrel Intended Status: Standards Track A. Farrel
Created: August 27, 2009 Old Dog Consulting Created: September 19, 2009 Old Dog Consulting
Expires: February 27, 2010 Expires: March 19, 2010
An Inband Data Communication Network For the MPLS Transport Profile An Inband Data Communication Network For the MPLS Transport Profile
draft-ietf-mpls-tp-gach-dcn-05.txt draft-ietf-mpls-tp-gach-dcn-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
skipping to change at page 2, line 33 skipping to change at page 2, line 33
The use of the ACH is generalized in [RFC5586] and can be applied on The use of the ACH is generalized in [RFC5586] and can be applied on
any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP). any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP).
This is referred to as the Generic Associated Channel (G-ACh) and is This is referred to as the Generic Associated Channel (G-ACh) and is
intended to create a control/management communication channel intended to create a control/management communication channel
associated with the LSP that can be used to carry packets used for associated with the LSP that can be used to carry packets used for
OAM and similar functions (e.g., control/management plane messages). OAM and similar functions (e.g., control/management plane messages).
The purpose of a packet carried on the G-ACh is indicated by the The purpose of a packet carried on the G-ACh is indicated by the
value carried by the Channel Type field of the ACH and a registry of value carried by the Channel Type field of the ACH and a registry of
values is maintained by IANA ([RFC4446] and [RFC4385]). The values is maintained by IANA ([RFC4446] and [RFC4385]). The
combination of the ACH and the ACH TLVs that may be appended to the
ACH is referred in this document as the G-ACh header. ACH is referred in this document as the G-ACh header.
The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in
[TP-REQ]. MPLS-TP is the application of MPLS to construct a packet [TP-REQ]. MPLS-TP is the application of MPLS to construct a packet
transport network. It constitutes a profile of MPLS that enables transport network. It constitutes a profile of MPLS that enables
operational models typical in transport networks, which includes operational models typical in transport networks, which includes
additional OAM, survivability and other maintenance functions not additional OAM, survivability and other maintenance functions not
previously supported by MPLS. previously supported by MPLS.
Label Switching Routers (LSRs) in MPLS networks may be operated using Label Switching Routers (LSRs) in MPLS networks may be operated using
skipping to change at page 3, line 33 skipping to change at page 3, line 33
the server layer does not provide a Management Communication the server layer does not provide a Management Communication
Channel (MCC) or a Signalling Communication Channel (SCC)). Channel (MCC) or a Signalling Communication Channel (SCC)).
b. The G-ACh is carried by an MPLS-TP tunnel that traverses b. The G-ACh is carried by an MPLS-TP tunnel that traverses
another operator's domain (carrier's carrier scenario) another operator's domain (carrier's carrier scenario)
3. The G-ACh shall provide two independent channels: an MCC to build 3. The G-ACh shall provide two independent channels: an MCC to build
the MCN and an SCC to build the SCN. The G-ACh packet header shall the MCN and an SCC to build the SCN. The G-ACh packet header shall
indicate whether the packet is an MCC or an SCC packet in order to indicate whether the packet is an MCC or an SCC packet in order to
forward it to the management or control plane application for forward it to the management or control plane application for
processing. processing. This facilitates easy demultiplexing of control and
management traffic from the DCN and enables separate or
overlapping address spaces and duplicate protocol instances in the
management and control planes.
4. The channel separation mechanism shall allow the use of separate 4. The channel separation mechanism shall not preclude the use of
rate limiters and traffic shaping functions for each channel (MCC separate rate limiters and traffic shaping functions for each
and SCC) ensuring that the flows do not exceed their assigned channel (MCC and SCC) ensuring that the flows do not exceed their
traffic profiles. The rate limiters and traffic shapers are assigned traffic profiles. The rate limiters and traffic shapers
outside the scope of the MCC and SCC definitions. are outside the scope of the MCC and SCC definitions.
5. The G-ACh that carries the MCC and SCC shall be capable of 5. The G-ACh that carries the MCC and SCC shall be capable of
carrying different OSI layer 3 (network layer) PDUs. These shall carrying different OSI layer 3 (network layer) PDUs. These shall
include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC 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 packet shall indicate which layer 3 PDU is contained in the
payload field of the packet such that the packet can be delivered payload field of the packet such that the packet can be delivered
to the related layer 3 process within the management and control to the related layer 3 process within the management and control
plane application, respectively, for further processing. plane application, respectively, for further processing.
6. The G-ACh is not required to provide specific security mechanisms. 6. The G-ACh is not required to provide specific security mechanisms.
However, the management or control plane protocols that operate However, the management or control plane protocols that operate
over the MCC or SCC are required to provide adequate security over the MCC or SCC are required to provide adequate security
mechanisms in order not to be susceptible to security attacks. mechanisms in order not to be susceptible to security attacks.
2. Procedures 2. Procedures
Figure 1 depicts the format of an MCC/SCC packet that is sent on the Figure 1 depicts the format of an MCC/SCC packet that is sent on the
G-ACh. The Channel Type field indicates the function of the ACH G-ACh. The Channel Type field indicates the function of the ACH
message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC
message is prepended with an ACH with the Channel Type set to message is prepended with an ACH with the Channel Type set to
indicate that the message is an MCC or SCC message. The ACH MUST indicate that the message is an MCC or SCC message. The ACH MUST NOT
include the ACH Protocol ID TLV [ACH-TLV] to identify the protocol include the ACH TLV Header [RFC5586] meaning that no ACH TLVs can be
type of the MCC or SCC message, and MAY include further ACH TLVs. included in the message. A two byte Protocol Identifier (PID) field
indicates the protocol type of the payload DCN message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header | | PID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ zero or more ACH TLVs ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH Protocol ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCC/SCC Message | | MCC/SCC Message |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: G-ACh MCC/SCC Packet Figure 1: G-ACh MCC/SCC Packet
o The Channel Type field determines whether the message is an MCC or o The Channel Type field determines whether the message is an MCC or
an SCC message. See Section 5 for the codepoint assignments. an SCC message. See Section 5 for the codepoint assignments.
o No other ACH TLV (except the ACH protocol ID TLV - see below) has o The presence of the PID field is deduced from the Channel Type
been identified for use on a DCN message. If a message is received value indicating MCC or SCC. The field contains an identifier of
carrying an ACH TLV that is not understood in the context of a DCN the payload protocol using the PPP protocol identifiers [RFC1661],
message, the ACH TLV SHOULD be silently ignored and processing of
the message SHOULD continue.
o The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC
message. The ACH MUST be present in a DCN message and MUST be
placed last in the sequence of ACH TLVs so that it comes
immediately before the MCC/SCC message. Note that this means that
the PID field of the TLV is immediately adjacent to the message
itself [ACH-TLV].
The ACH Protocol ID TLV is defined in [ACH-TLV] and uses the PPP
protocol identifiers to distinguish different protocols [RFC1661],
[RFC3818]. [RFC3818].
When the G-ACh sender receives an MCC message that is to be sent over When the G-ACh sender receives an MCC message that is to be sent over
the MCC, the sender creates the G-ACh header, provides an ACH the MCC, the sender creates the G-ACh header, sets the Channel
Protocol ID TLV indicating the MCC layer 3 PDU type, sets the Channel Type field to MCC, fills in the PID to indicate the MCC layer 3 PDU
Type field to MCC, and prepends the MCC message with the G-ACh type,and prepends the MCC message with the G-ACh header. The same
header. The same procedure is applied when a control plane message is procedure is applied when a control plane message is to be sent over
to be sent over the SCC. In this case, the sender sets the Channel the SCC. In this case, the sender sets the Channel Type field to SCC.
Type field to SCC.
If the G-ACh is associated with an MPLS section, the GAL is added to If the G-ACh is associated with an MPLS section, the GAL is added to
the message as defined in [RFC5586]. The TTL field MUST be set to 1, the message as defined in [RFC5586]. The TTL field MUST be set to 1,
and the S-bit of the GAL MUST 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 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 packet and the LSP label is pushed on top of the GAL as defined in
[RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit [RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit
of the GAL MUST be set to 1. of the GAL MUST be set to 1.
Note that packet processing for DCN packets in the G-ACh is, in
common with all G-ACh MPLS packets, subject to the normal processing
of the Traffic Class (TC) field of the MPLS header. This could be
used to enable prioritisation of different DCN packets.
The DCN channel MUST NOT be used to transport user traffic and SHALL The DCN channel MUST NOT be used to transport user traffic and SHALL
only be used to carry management or control plane messages. only be used to carry management or control plane messages.
Procedures that ensure this (such as deep packet inspection) are Procedures that ensure this (such as deep packet inspection) are
outside the scope of this specification. outside the scope of this specification.
When a receiver has received a packet on the G-ACh with the ACH When a receiver has received a packet on the G-ACh with the ACH
Channel Type set to MCC or SCC, it SHALL look at the PID field Channel Type set to MCC or SCC, it SHALL look at the PID field. If
carried in the ACH Protocol ID TLV. If the TLV is absent, the message the PID value is known by the receiver it delivers the the MCC/SCC
SHALL be silently discarded, although a local system MAY increment a message to the appropriate processing entity. If the PID value is
counter that records discarded or errored packets, and MAY log an unknown, the receiver SHALL silently discard the received packet,
event. If the PID value is known by the receiver it delivers the MAY increment a counter that records discarded or errored messages,
the MCC/SCC message to the appropriate processing entity. If the PID and MAY log an event.
value is unknown, the receiver SHALL silently discard the received
packet, MAY increment a counter that records discarded or errored
messages, and MAY log an event.
It must be noted that according to [RFC5586] a receiver MUST NOT It must be noted that according to [RFC5586] a receiver MUST NOT
forward a GAL packet based on the GAL label as is normally the case 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 for MPLS packets. If the GAL appears at the bottom of the label
stack, it MUST be processed as described in the previous paragraph. stack, it MUST be processed as described in the previous paragraph.
Note that there is no requirement for MPLS-TP devices to support IP Note that there is no requirement for MPLS-TP devices to support IP
or OSI forwarding in the fast (forwarding) path. Thus, if a message or OSI forwarding in the fast (forwarding) path. Thus, if a message
is received on the MCC or SCC and is not targeted to an address of is received on the MCC or SCC and is not targeted to an address of
the receiving MPLS-TP node the packet might not be forwarded in the the receiving MPLS-TP node the packet might not be forwarded in the
fast path. A node MAY apply layer 3 forwarding procedures in the slow fast path. A node MAY apply layer 3 forwarding procedures in the slow
path and MAY discard or reject the message using the layer 3 protocol or fast path and MAY discard or reject the message using the layer 3
if it is unable to forward it. Thus, protocols making use of the DCN protocol if it is unable to forward it. Thus, protocols making use of
should make no assumptions about the forwarding capabilities unless the DCN should make no assumptions about the forwarding capabilities
they are determined a priori or through the use of a routing unless they are determined a priori or through the use of a routing
protocol. Furthermore it is important that user data (i.e., data protocol. Furthermore it is important that user data (i.e., data
traffic) is not routed through the DCN as this would potentially traffic) is not routed through the DCN as this would potentially
cause the traffic to be lost or delayed, and might significantly cause the traffic to be lost or delayed, and might significantly
congest the DCN. congest the DCN.
2.1. Pseudowire Setup 2.1. Pseudowire Setup
Provider Edge nodes may wish to set up PWs using a signaling protocol Provider Edge nodes may wish to set up PWs using a signaling protocol
that uses remote adjacencies (such as LDP [RFC5036]). In the absence that uses remote adjacencies (such as LDP [RFC5036]). In the absence
of an IP-based control plane network, these PEs MUST first set up an of an IP-based control plane network, these PEs MUST first set up an
skipping to change at page 7, line 30 skipping to change at page 7, line 20
[RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge [RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge
(PWE3) Control Word for Use over an MPLS PSN", RFC 4385, (PWE3) Control Word for Use over an MPLS PSN", RFC 4385,
February 2006. February 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", RFC 4446, April 2006 . Emulation (PWE3)", RFC 4446, April 2006 .
[RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[ACH-TLV] Bryant, S., et al., "Definition of ACH TLV Structure",
draft-bryant-mpls-tp-ach-tlv, work in progress.
7. Informative References 7. Informative References
[MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS [MPLS-TP] Bryant, S., Bocci, M., Lasserre, M., "A Framework for MPLS
in Transport Networks", draft-ietf-mpls-tp-framework, work in Transport Networks", draft-ietf-mpls-tp-framework, work
in progress. in progress.
[TP-REQ] B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., [TP-REQ] B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed.,
N. Sprecher, S. Ueno, "MPLS-TP Requirements", N. Sprecher, S. Ueno, "MPLS-TP Requirements",
draft-ietf-mpls-tp-requirements, work in progress. draft-ietf-mpls-tp-requirements, work in progress.
skipping to change at page 8, line 14 skipping to change at page 8, line 8
[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point
Protocol (PPP)", BCP 88, RFC 3818, June 2004. Protocol (PPP)", BCP 88, RFC 3818, June 2004.
[RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP [RFC5036] Andersson, L., Minei, I., and Thomas, B., "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
8. Acknowledgements 8. Acknowledgements
The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam, The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam,
Ben Niven-Jenkins, and Francesco Fondelli for their contribution to Ben Niven-Jenkins, Francesco Fondelli, Walter Rothkegel, Shahram
this document, and the MEAD team for thorough review. Davari, Liu Guoman, and Alexander Vainshtein for their contribution
to this document, and the MEAD team for thorough review.
Study Group 15 of the ITU-T provided the basis for the requirements Study Group 15 of the ITU-T provided the basis for the requirements
text in Section 1.1. text in Section 1.1.
9. Authors' Addresses 9. Authors' Addresses
Dieter Beller Dieter Beller
Alcatel-Lucent Germany Alcatel-Lucent Germany
EMail: dieter.beller@alcatel-lucent.com EMail: dieter.beller@alcatel-lucent.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Full Copyright Statement 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
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 Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your rights
rights and restrictions with respect to this document. and restrictions with respect to this document.
 End of changes. 17 change blocks. 
114 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/