draft-ietf-mpls-tp-gach-gal-05.txt   draft-ietf-mpls-tp-gach-gal-06.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft M. Vigoureux, Ed. Internet-Draft M. Vigoureux, Ed.
Updates: 3032, 4385, 5085 Alcatel-Lucent Updates: 3032, 4385, 5085 Alcatel-Lucent
(if approved) G. Swallow (if approved) S. Bryant
Intended status: Standards Track D. Ward Intended status: Standards Track Cisco
Expires: November 17, 2009 S. Bryant Expires: November 22, 2009
Cisco
R. Aggarwal May 21, 2009
Juniper Networks
May 16, 2009
MPLS Generic Associated Channel MPLS Generic Associated Channel
draft-ietf-mpls-tp-gach-gal-05 draft-ietf-mpls-tp-gach-gal-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with 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.
skipping to change at page 1, line 38 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 17, 2009. This Internet-Draft will expire on November 22, 2009.
Copyright Notice Copyright Notice
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 rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7 3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7
3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8 3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8
3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8 3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8
4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9 4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9
4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9 4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9
4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10 4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10
4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10 4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10
4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13 4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 15 7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
There is a need for Operations, Administration and Maintenance (OAM) There is a need for Operations, Administration and Maintenance (OAM)
mechanisms that can be used for fault detection, diagnostics, mechanisms that can be used for fault detection, diagnostics,
maintenance and other functions on a pseudowire (PW) and a Label maintenance and other functions on a pseudowire (PW) and a Label
Switched Path (LSP). These functions can be used between any two Switched Path (LSP). These functions can be used between any two
Label Edge Routers (LERs) / Label Switching Router (LSRs) or Label Edge Routers (LERs) / Label Switching Router (LSRs) or
Terminating Provider Edge routers (T-PEs) / Switching Provider Edge Terminating Provider Edge routers (T-PEs) / Switching Provider Edge
routers (S-PEs) along the path of an LSP or PW respectively [11]. routers (S-PEs) along the path of an LSP or PW respectively [11].
skipping to change at page 5, line 33 skipping to change at page 5, line 33
The terms 'Section' and 'Concatenated Segment' are defined in [16] as The terms 'Section' and 'Concatenated Segment' are defined in [16] as
follows (note that the terms 'Section' and 'Section Layer Network' follows (note that the terms 'Section' and 'Section Layer Network'
are synonymous): are synonymous):
Concatenated Segment: A serial-compound link connection as defined in Concatenated Segment: A serial-compound link connection as defined in
[17]. A concatenated segment is a contiguous part of an LSP or [17]. A concatenated segment is a contiguous part of an LSP or
multi-segment PW that comprises a set of segments and their multi-segment PW that comprises a set of segments and their
interconnecting nodes in sequence. interconnecting nodes in sequence.
Section Layer Network: A section is a server layer (which may be Section Layer Network: A section layer is a server layer (which may
MPLS-TP or a different technology) which provides for encapsulation be MPLS-TP or a different technology) which provides for the transfer
and OAM of a client layer network. A section layer may provide for of the section layer client information between adjacent nodes in the
aggregation of multiple MPLS-TP clients. Note that G.805 [17] transport path layer or transport service layer. Note that G.805
defines the section layer as one of the two layer networks in a [17] defines the section layer as one of the two layer networks in a
transmission media layer network. The other layer network is the transmission media layer network. The other layer network is the
physical media layer network. physical media layer network.
2. Generic Associated Channel Header 2. Generic Associated Channel Header
VCCV [1] defines three Control Channel (CC) Types that may be used to VCCV [1] defines three Control Channel (CC) Types that may be used to
exchange OAM messages through a PW: CC Type 1 uses an ACH and is exchange OAM messages through a PW: CC Type 1 uses an ACH and is
referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router Alert referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router Alert
Label to indicate VCCV packets and is referred to as "Out of Band Label to indicate VCCV packets and is referred to as "Out of Band
VCCV"; CC Type 3 uses the TTL to force the packet to be processed by VCCV"; CC Type 3 uses the TTL to force the packet to be processed by
skipping to change at page 6, line 27 skipping to change at page 6, line 27
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Associated Channel Header Figure 1: Associated Channel Header
In the above figure, the first nibble is set to 0001b to indicate a In the above figure, the first nibble is set to 0001b to indicate a
control channel associated with a PW, an LSP or a Section. The control channel associated with a PW, an LSP or a Section. The
Version field is set to 0, as specified in RFC 4385 [2]. Bits 8 to Version field is set to 0, as specified in RFC 4385 [2]. Bits 8 to
15 of the ACH are reserved and MUST be set to 0 and ignored on 15 of the ACH are reserved and MUST be set to 0 and ignored on
reception. Bits 16 to 31 are used to encode the possible Channel reception. Bits 16 to 31 are used to encode the possible Channel
Types. Types. This 16 bit field is in network byte order.
Note that VCCV [1] also includes mechanisms for negotiating the Note that VCCV [1] also includes mechanisms for negotiating the
Control Channel and Connectivity Verification (i.e., OAM function) Control Channel and Connectivity Verification (i.e., OAM function)
Types between PEs. It is anticipated that similar mechanisms will be Types between PEs. It is anticipated that similar mechanisms will be
applied to LSPs. Such application will require further applied to LSPs. Such application will require further
specification. However, such specification is beyond the scope of specification. However, such specification is beyond the scope of
this document. this document.
The G-ACh MUST NOT be used to transport user traffic. The G-ACh MUST NOT be used to transport user traffic.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
The Length field specifies the length in octets of the complete set The Length field specifies the length in octets of the complete set
of TLVs including sub-TLVs that follow the ACH TLV header. A length of TLVs including sub-TLVs that follow the ACH TLV header. A length
of zero indicates that no ACH TLV follow this header. Note that no of zero indicates that no ACH TLV follow this header. Note that no
padding is required for the set of ACH TLVs. padding is required for the set of ACH TLVs.
The Reserved field is for future use and MUST be set to zero on The Reserved field is for future use and MUST be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
3.3. ACH TLV Object 3.3. ACH TLV Object
The structure of ACH TLVs that MAY follow an ACH TLV Header is ACH TLVs MAY follow an ACH TLV header. The structure of ACH TLVs is
defined and described in this section. defined and described in this section.
An ACH TLV consists of a 16-bit Type field, followed by a 16-bit An ACH TLV consists of a 16-bit Type field, followed by a 16-bit
Length field which specifies the number of octets of the Value field Length field which specifies the number of octets of the Value field
which follows the Length field. This 32-bit word is followed by zero which follows the Length field. This 32-bit word is followed by zero
or more octets of Value information. The format and semantics of the or more octets of Value information. The format and semantics of the
Value information are defined by the TLV Type as recorded in the TLV Value information are defined by the TLV Type as recorded in the TLV
Type registry. See Section 10 for further details. Note that the Type registry. See Section 10 for further details. Note that the
Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding
is required for individual TLVs or sub-TLVs. is required for individual TLVs or sub-TLVs.
skipping to change at page 12, line 12 skipping to change at page 12, line 12
LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards
the targeted destination. the targeted destination.
Note: This is because once a G-ACh packet has been sent on an LSP, Note: This is because once a G-ACh packet has been sent on an LSP,
no node has visibility of it unless the LSP label TTL expires or no node has visibility of it unless the LSP label TTL expires or
the GAL is exposed when the LSP label is popped. If this is at the GAL is exposed when the LSP label is popped. If this is at
the targeted destination, for example indicated by an address in the targeted destination, for example indicated by an address in
an ACH TLV, then processing can proceed as specified below. If an ACH TLV, then processing can proceed as specified below. If
this is not the targeted destination, but the node has agreed to this is not the targeted destination, but the node has agreed to
process packets on that ACH channel, then the processing applied process packets on that ACH channel, then the processing applied
to the packet is out of scope of this docuemnt. However, the ACH to the packet is out of scope of this document.
type MUST be maintained if the packet is forwarded unmodified to
another node.
Upon reception of the labeled packet, the targeted destination, after Upon reception of the labeled packet, the targeted destination, after
having checked both the LSP Label and GAL LSEs fields, SHOULD pass having checked both the LSP Label and GAL LSEs fields, SHOULD pass
the whole packet to the appropriate processing entity. the whole packet to the appropriate processing entity.
4.2.1.2. MPLS Section 4.2.1.2. MPLS Section
The following figure (Figure 7) depicts an example of an MPLS The following figure (Figure 7) depicts an example of an MPLS
Section. Section.
skipping to change at page 15, line 10 skipping to change at page 15, line 10
o The ACH version is not recognized. o The ACH version is not recognized.
In addition, the LER, LSR or PE MAY increment an error counter and In addition, the LER, LSR or PE MAY increment an error counter and
MAY also issue a system and/or SNMP notification. MAY also issue a system and/or SNMP notification.
6. Congestion Considerations 6. Congestion Considerations
The congestion considerations detailed in RFC 5085 [1] apply. The congestion considerations detailed in RFC 5085 [1] apply.
7. Contributing Authors 7. Major Contributing Authors
The editors gratefully acknowledge the contributions of Sami Boutros, The editors would like to thank George Swallow, David Ward, and Rahul
Italo Busi, Marc Lasserre, Lieven Levrau and Siva Sivabalan Aggarwal, who made a major contribution to the developement of this
document.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Malcolm Betts, ITU-T Study Group 15, The editors gratefully acknowledge the contributions of Sami Boutros,
and all members of the teams (the Joint Working Team, the MPLS Italo Busi, Marc Lasserre, Lieven Levrau and Siva Sivabalan.
The authors would also like to thank Malcolm Betts, ITU-T Study Group
15, and all members of the teams (the Joint Working Team, the MPLS
Interoperability Design Team in IETF and the MPLS-TP Ad-Hoc Team in Interoperability Design Team in IETF and the MPLS-TP Ad-Hoc Team in
ITU-T) involved in the definition and specification of the MPLS ITU-T) involved in the definition and specification of the MPLS
Transport Profile. Transport Profile.
9. Security Considerations 9. Security Considerations
The security considerations for the associated control channel are The security considerations for the associated control channel are
described in RFC 4385 [2]. Further security considerations MUST be described in RFC 4385 [2]. Further security considerations MUST be
described in the relevant associated channel type specification. described in the relevant associated channel type specification.
skipping to change at page 16, line 22 skipping to change at page 16, line 30
optimizations or extensions to OAM and other control protocols optimizations or extensions to OAM and other control protocols
running in an associated channel to be experimented without resorting running in an associated channel to be experimented without resorting
to the IETF standards process, by supporting experimental code to the IETF standards process, by supporting experimental code
points. This would prevent code points used for such functions from points. This would prevent code points used for such functions from
being used from the range allocated through the IETF standards and being used from the range allocated through the IETF standards and
thus protects an installed base of equipment from potential thus protects an installed base of equipment from potential
inadvertent overloading of code points. In order to support this inadvertent overloading of code points. In order to support this
requirement, this document requests that the code point allocation requirement, this document requests that the code point allocation
scheme for the PW Associated Channel Type be changed as follows: scheme for the PW Associated Channel Type be changed as follows:
0 - 32751 : IETF Consensus 0 - 32751 : IETF Review
32760 - 32767 : Experimental 32760 - 32767 : Experimental
Code points in the experimental range MUST be used according to the Code points in the experimental range MUST be used according to the
guidelines of RFC 3692 [10]. Functions using experimental G-ACh code guidelines of RFC 3692 [10]. Functions using experimental G-ACh code
points MUST be disabled by default. The Channel Type value used for points MUST be disabled by default. The Channel Type value used for
a given experimental OAM function MUST be configurable, and care MUST a given experimental OAM function MUST be configurable, and care MUST
be taken to ensure that different OAM functions that are not inter- be taken to ensure that different OAM functions that are not inter-
operable are configured to use different Channel Type values. operable are configured to use different Channel Type values.
skipping to change at page 18, line 31 skipping to change at page 18, line 45
Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-04 Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-04
(work in progress), May 2009. (work in progress), May 2009.
[15] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in [15] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in
MPLS Transport Networks", MPLS Transport Networks",
draft-ietf-mpls-tp-oam-requirements-01 (work in progress), draft-ietf-mpls-tp-oam-requirements-01 (work in progress),
March 2009. March 2009.
[16] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and [16] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
S. Ueno, "MPLS-TP Requirements", S. Ueno, "MPLS-TP Requirements",
draft-ietf-mpls-tp-requirements-06 (work in progress), draft-ietf-mpls-tp-requirements-08 (work in progress),
April 2009. May 2009.
[17] International Telecommunication Union, "Generic Functional [17] International Telecommunication Union, "Generic Functional
Architecture of Transport Networks", ITU-T G.805, March 2000. Architecture of Transport Networks", ITU-T G.805, March 2000.
[18] Ohta, H., "Assignment of the 'OAM Alert Label' for [18] Ohta, H., "Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS) Operation and Multiprotocol Label Switching Architecture (MPLS) Operation and
Maintenance (OAM) Functions", RFC 3429, November 2002. Maintenance (OAM) Functions", RFC 3429, November 2002.
Authors' Addresses Authors' Addresses
skipping to change at page 19, line 4 skipping to change at page 19, line 16
Authors' Addresses Authors' Addresses
Matthew Bocci (editor) Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Voyager Place, Shoppenhangers Road Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ Maidenhead, Berks SL6 2PJ
UK UK
Email: matthew.bocci@alcatel-lucent.com Email: matthew.bocci@alcatel-lucent.com
Martin Vigoureux (editor) Martin Vigoureux (editor)
Alcatel-Lucent Alcatel-Lucent
Route de Villejust Route de Villejust
Nozay, 91620 Nozay, 91620
France France
Email: martin.vigoureux@alcatel-lucent.com Email: martin.vigoureux@alcatel-lucent.com
Stewart Bryant
Cisco
Email: stbryant@cisco.com
George Swallow George Swallow
Cisco Cisco
Email: swallow@cisco.com Email: swallow@cisco.com
David Ward David Ward
Cisco Cisco
Email: dward@cisco.com Email: dward@cisco.com
Stewart Bryant
Cisco
Email: stbryant@cisco.com
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
Email: rahul@juniper.net Email: rahul@juniper.net
 End of changes. 17 change blocks. 
34 lines changed or deleted 35 lines changed or added

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