draft-ietf-mpls-tp-mip-mep-map-00.txt   draft-ietf-mpls-tp-mip-mep-map-01.txt 
Network Working Group A. Farrel Network Working Group A. Farrel
Internet-Draft Huawei Technologies Internet-Draft Juniper Networks
Intended status: Informational H. Endo Intended status: Informational H. Endo
Expires: June 21, 2012 Hitachi, Ltd. Expires: September 13, 2012 Hitachi, Ltd.
R. Winter R. Winter
NEC NEC
Y. Koike Y. Koike
NTT NTT
M. Paul M. Paul
Deutsche Telekom Deutsche Telekom
December 19, 2011 March 12, 2012
Handling MPLS-TP OAM Packets Targeted at Internal MIPs Handling MPLS-TP OAM Packets Targeted at Internal MIPs
draft-ietf-mpls-tp-mip-mep-map-00 draft-ietf-mpls-tp-mip-mep-map-01
Abstract Abstract
The Framework for Operations, Administration and Maintenance (OAM) The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP) describes how Maintenance within the MPLS Transport Profile (MPLS-TP) describes how Maintenance
Entity Group Intermediate Points (MIPs) may be situated within Entity Group Intermediate Points (MIPs) may be situated within
network nodes at the incoming and outgoing interfaces. network nodes at the incoming and outgoing interfaces.
This document describes a way of forming OAM messages so that they This document describes a way of forming OAM messages so that they
can be targeted at MIPs on incoming or MIPs on outgoing interfaces, can be targeted at MIPs on incoming or MIPs on outgoing interfaces,
forwarded correctly through the "switch fabric", and handled forwarded correctly through the "switch fabric", and handled
efficiently in node implementations where there is no distinction efficiently in node implementations where there is no distinction
between the incoming and outgoing MIP. between the incoming and outgoing MIP.
The material in this document is provided for discussion within the
MPLS-TP community in the expectation that this idea or some similar
mechanism will be subsumed into a more general MPLS-TP OAM document.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network. capabilities and functionalities of a packet transport network.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 10 skipping to change at page 2, line 6
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 June 21, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 22 skipping to change at page 3, line 22
5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10 5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10
6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11 6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Previously considered solutions . . . . . . . . . . . 13 Appendix A. Previously considered solutions . . . . . . . . . . . 13
A.1. GAL TTL . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.1. GAL TTL . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2. A separate channel type for the out-MIP . . . . . . . . . 13 A.2. A separate channel type for the out-MIP . . . . . . . . . 14
A.3. Decrement TTL once per MIP . . . . . . . . . . . . . . . . 13 A.3. Decrement TTL once per MIP . . . . . . . . . . . . . . . . 14
A.4. Using an ACH reserved bit . . . . . . . . . . . . . . . . 14 A.4. Using an ACH reserved bit . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Framework for Operations, Administration and Maintenance (OAM) The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM
Framework, [RFC6371]) distinguishes two configurations for Framework, [RFC6371]) distinguishes two configurations for
Maintenance Entity Group Intermediate Points (MIPs) on a node. It Maintenance Entity Group Intermediate Points (MIPs) on a node. It
defines per-node MIPs and per-interface MIPs, where a per-node MIP is defines per-node MIPs and per-interface MIPs, where a per-node MIP is
skipping to change at page 4, line 28 skipping to change at page 4, line 28
pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using
the expiration of the MPLS shim header time-to-live (TTL) field. OAM the expiration of the MPLS shim header time-to-live (TTL) field. OAM
messages for the end points of PWs and LSPs are simply delivered as messages for the end points of PWs and LSPs are simply delivered as
normal. normal.
OAM messages delivered to end points or transit points are OAM messages delivered to end points or transit points are
distinguished from other (data) packets so that they can be processed distinguished from other (data) packets so that they can be processed
as OAM. In LSPs, the mechanism used is the presence of the Generic as OAM. In LSPs, the mechanism used is the presence of the Generic
Associated Channel Label (GAL) in the Label Stack Entry (LSE) under Associated Channel Label (GAL) in the Label Stack Entry (LSE) under
the top LSE [RFC5586]. In PWs, the mechanism used is the presence of the top LSE [RFC5586]. In PWs, the mechanism used is the presence of
the PW Associated Channel Header (PWACH) [RFC4385]. the PW Associated Channel Header (PWACH) [RFC4385] or the presence of
a GAL [RFC6423].
In case multiple MIPs are present on a single node, these mechanisms In case multiple MIPs are present on a single node, these mechanisms
alone provide no way to address one particular MIP out of the set of alone provide no way to address one particular MIP out of the set of
MIPs. MIPs.
This document describes a way of forming OAM messages so that they This document describes a way of forming OAM messages so that they
can be targeted at incoming MIPs and outgoing MIPs, forwarded can be targeted at incoming MIPs and outgoing MIPs, forwarded
correctly through the "switch fabric", and handled efficiently in correctly through the "switch fabric", and handled efficiently in
node implementations where there is no distinction between the node implementations where there is no distinction between the
incoming and outgoing MIP. incoming and outgoing MIP.
skipping to change at page 5, line 43 skipping to change at page 5, line 43
------------------------ ------------------------
Figure 1: Abstract Functional Representation of an MPLS-TP Node Figure 1: Abstract Functional Representation of an MPLS-TP Node
Several distinct OAM functions are required within this architectural Several distinct OAM functions are required within this architectural
model such as: model such as:
o CV between a MEP and a MIP o CV between a MEP and a MIP
o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing
MIPs MIPs
o OAM control at a MIP
o data-plane loopback at a MIP o data-plane loopback at a MIP
o diagnostic tests o diagnostic tests
The MIPs in these OAM functions may equally be the MIPs at the The MIPs in these OAM functions may equally be the MIPs at the
incoming or outgoing interfaces. incoming or outgoing interfaces.
Per-interface MIPs have the advantage that they enable a more Per-interface MIPs have the advantage that they enable a more
accurate localization and identification of faults and targeted accurate localization and identification of faults and targeted
performance monitoring or diagnostic test. In particular, the performance monitoring or diagnostic test. In particular, the
identification of whether a problem is located between nodes or on a identification of whether a problem is located between nodes or on a
skipping to change at page 8, line 13 skipping to change at page 8, line 11
points of PWs or LSPs are delivered using the expiration of the time- points of PWs or LSPs are delivered using the expiration of the time-
to-live (TTL) field in the top LSE of the MPLS packet header. OAM to-live (TTL) field in the top LSE of the MPLS packet header. OAM
messages for the end points of PWs and LSPs are simply delivered as messages for the end points of PWs and LSPs are simply delivered as
normal. normal.
OAM messages delivered to end points or transit points are OAM messages delivered to end points or transit points are
distinguished from other (data) packets so that they can be processed distinguished from other (data) packets so that they can be processed
as OAM. In LSPs, the mechanism used is the presence of the Generic as OAM. In LSPs, the mechanism used is the presence of the Generic
Associated Channel Label (GAL) in the LSE under the top LSE Associated Channel Label (GAL) in the LSE under the top LSE
[RFC5586]. In PWs, the mechanism used is the presence of the PW [RFC5586]. In PWs, the mechanism used is the presence of the PW
Associated Channel Header [RFC4385]. Associated Channel Header [RFC4385] or the presence of a GAL
[RFC6423].
Any solution for sending OAM to the in and out-MIPs must fit within Any solution for sending OAM to the in and out-MIPs must fit within
these existing models of handling OAM. these existing models of handling OAM.
Additionally, many MPLS-TP nodes contain an optimization such that Additionally, many MPLS-TP nodes contain an optimization such that
all queuing and the forwarding function is performed at the incoming all queuing and the forwarding function is performed at the incoming
interface. The abstract functional representation of such a node is interface. The abstract functional representation of such a node is
shown in Figure 4. As shown in the figure, the outgoing interfaces shown in Figure 4. As shown in the figure, the outgoing interfaces
are minimal and for this reason it may not be possible to include MIP are minimal and for this reason it may not be possible to include MIP
functions on those interfaces. This is in particular the case for functions on those interfaces. This is in particular the case for
skipping to change at page 11, line 22 skipping to change at page 11, line 22
presented in this section. The appendix of this document contains a presented in this section. The appendix of this document contains a
few solutions that the authors have discarded which have been left in few solutions that the authors have discarded which have been left in
the document for informational purposes. the document for informational purposes.
Per-interface MIP addressing should not require changes to existing Per-interface MIP addressing should not require changes to existing
OAM solutions. Therefore, ID information that specific OAM OAM solutions. Therefore, ID information that specific OAM
mechanisms already contain should be (re-)used to address the MIPs on mechanisms already contain should be (re-)used to address the MIPs on
a node. Upcoming OAM solutions therefore need to individually make a node. Upcoming OAM solutions therefore need to individually make
sure that enough of that information is present to support the per- sure that enough of that information is present to support the per-
interface model. In particular, the MIP identifiers as described in interface model. In particular, the MIP identifiers as described in
[RFC6370] need to be present in OAM messages. [RFC6370] defines a [RFC6370] or [I-D.ietf-mpls-tp-itu-t-identifiers] need to be present
format that supports the per-interface model which is sufficient for in OAM messages. [RFC6370] and [I-D.ietf-mpls-tp-itu-t-identifiers]
this purpose. In addition, some constraints must be agreed on. define formats that support the per-interface model which is
sufficient for this purpose. In addition, some constraints must be
agreed on.
Regarding the features we required earlier from a solution this Regarding the features we required earlier from a solution this
translates to: translates to:
o Feature 1: "Forwarding of OAM packets exactly as data packets" o Feature 1: "Forwarding of OAM packets exactly as data packets"
* This way of internal-MIP addressing has no implications on the * Using existing ID information in OAM messages for internal-MIP
way data packets and non-local OAM packets are handled as the addressing has no implications on the way data packets and non-
label stack is not altered for the purpose of MIP addressing. local OAM packets are handled as the label stack is not altered
Also the TTL processing remains untouched. This means that the for the purpose of MIP addressing. Also the TTL processing
TTL will expire on the ingress. remains untouched. This means that the TTL will expire on the
ingress.
o Feature 2: "Delivery of OAM messages to the correct MPLS-TP node" o Feature 2: "Delivery of OAM messages to the correct MPLS-TP node"
* The node itself is addresses using TTL expiry, comparable to * The node itself is addresses using TTL expiry, comparable to
the per-node MIP addressing case. the per-node MIP addressing case.
o Feature 3: "Delivery of OAM instructions to the correct MIP within o Feature 3: "Delivery of OAM instructions to the correct MIP within
an MPLS-TP node" an MPLS-TP node"
* The ID information containted in the OAM packet is used to tell * The ID information containted in the OAM packet is used to tell
whether the packet is for the in or out-MIP. whether the packet is for the in-MIP or the out-MIP.
o Feature 4: "Packet inspection at the incoming and outgoing o Feature 4: "Packet inspection at the incoming and outgoing
interfaces must be minimized" interfaces must be minimized"
* Additional packet inspection compared to the per-node case is * Additional packet inspection compared to the per-node case is
inevitably needed. The ID information indside the OAM message inevitably needed. The ID information indside the OAM message
needs to be considered in order to deliver the packet to the needs to be considered in order to deliver the packet to the
right MIP. correct MIP.
The above illustrates how in principle per-MIP addressing operates. The above illustrates how in principle per-MIP addressing operates.
Another issue of concern was the correct filtering of OAM messages at Another issue of concern was the correct filtering of OAM messages at
a downstream node, that were intended for an upstream node's outgoing a downstream node, that were intended for an upstream node's outgoing
MIP. Since OAM messages expire on the ingress, the legacy upstream MIP. Since OAM messages expire on the ingress, the legacy upstream
neighbor will actually process the packet. Since the ID information neighbor will actually process the packet. Since the ID information
is not correct, the node should discard that packet. Leakage should is not correct, the node should discard that packet. Leakage should
therefore not occur. therefore not occur.
7. Security Considerations 7. Security Considerations
skipping to change at page 12, line 40 skipping to change at page 12, line 44
9. Acknowledgments 9. Acknowledgments
The authors gratefully acknowledge the substantial contributions of The authors gratefully acknowledge the substantial contributions of
Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros
for interesting input to this document through discussions. for interesting input to this document through discussions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-mpls-tp-itu-t-identifiers]
Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP
Identifiers Following ITU-T Conventions",
draft-ietf-mpls-tp-itu-t-identifiers-03 (work in
progress), March 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, February 2006.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks", Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011. RFC 6371, September 2011.
[RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the
Generic Associated Channel Label for Pseudowire in the
MPLS Transport Profile (MPLS-TP)", RFC 6423,
November 2011.
10.2. Informative References 10.2. Informative References
[I-D.ietf-mpls-tp-security-framework] [I-D.ietf-mpls-tp-security-framework]
Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
Security Framework", Security Framework",
draft-ietf-mpls-tp-security-framework-01 (work in draft-ietf-mpls-tp-security-framework-01 (work in
progress), May 2011. progress), May 2011.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
skipping to change at page 14, line 23 skipping to change at page 14, line 40
out-MIP is addressed. An advantage of this approach is that there is out-MIP is addressed. An advantage of this approach is that there is
no semantic overlap with anything that exists today, as the bits are no semantic overlap with anything that exists today, as the bits are
not in use. Existing implementations need to ignore it. That means not in use. Existing implementations need to ignore it. That means
that existing implementations will process the OAM packets at the in- that existing implementations will process the OAM packets at the in-
MIP/per-node MIP. ID information is still needed however for the MIP/per-node MIP. ID information is still needed however for the
P2MP case as a single bit is not enough. P2MP case as a single bit is not enough.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Huawei Technologies Juniper Networks
Email: adrian.farrel@huawei.com Email: adrian@olddog.co.uk
Hideki Endo Hideki Endo
Hitachi, Ltd. Hitachi, Ltd.
Email: hideki.endo.es@hitachi.com Email: hideki.endo.es@hitachi.com
Rolf Winter Rolf Winter
NEC NEC
Email: rolf.winter@neclab.eu Email: rolf.winter@neclab.eu
Yoshinori Koike Yoshinori Koike
NTT NTT
Email: koike.yoshinori@lab.ntt.co.jp Email: koike.yoshinori@lab.ntt.co.jp
 End of changes. 20 change blocks. 
28 lines changed or deleted 38 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/