MPLS Working Group Y.Koike, Ed.
Internet Draft T.Hamano
M.Namiki
NTT
Intended status: Informational
Expires: January 8, 2013 July 9, 2012
A framework for Point-to-Multipoint MPLS-TP OAM in case that return
paths don't exist
draft-hmk-mpls-tp-p2mp-oam-framework-00.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
This Internet-Draft will expire on January 8, 2013.
Copyright Notice
Copyright (c) 2011 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
Koike, et al. Expires January X, 2013 [Page 1]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
(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.
Abstract
The MPLS transport profile (MPLS-TP) is being standardized to enable
carrier-grade packet transport.
This document provides texts proposal which should be discussed and
included in draft-fbb-mpls-tp-p2mp-framework, particularly focusing
on p2mp OAM framework in case that return paths don't exist. Other
requirements of p2mp transport path such as protection will also be
discussed.
Note: This I-D was made based on the result of discussion in ITU-T
SG15 which is described in a Liaison Statement: Request advance work
on the p2mp framework in MPLS-TP
(https://datatracker.ietf.org/liaison/1163/)
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 4
2.1. Terminology ............................................ 4
2.2. Definitions ............................................ 4
3. P2MP OAM .................................................... 4
3.1. OAM functions for proactive monitoring ..................5
3.1.1. Continuity Check and Connectivity Verification..... 5
3.1.2. Remote Defect Indication........................... 6
Koike, et al. Expires January 8, 2013 [Page 2]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
3.1.3. Alarm Reporting.................................... 6
3.1.4. Lock Reporting..................................... 7
3.1.5. Packet Loss Measurement............................ 7
3.1.6. Packet Delay Measurement........................... 7
3.1.7. Client Failure Indication ..........................7
3.2. OAM functions for on-demand monitoring ..................7
3.2.1. Connectivity verification ..........................7
3.2.2. Packet loss measurement............................ 8
3.2.3. Diagnostic tests................................... 9
3.2.4. Route Tracing...................................... 9
3.2.5. Packet delay measurement........................... 9
3.3. OAM functions for administration control................ 9
3.3.1. Lock Instruct...................................... 9
4. Security Considerations...................................... 9
5. IANA Considerations ......................................... 9
6. References .................................................. 9
6.1. Normative References.................................... 9
6.2. Informative References................................. 10
7. Acknowledgments ............................................ 10
1. Introduction
The demand for P2MP traffic is expected to increase due to the
increase in new services such as IP-TV and video distribution
services. Moreover considering the global trend to improve energy
efficiency, a P2MP transport function in MPLS-TP could be one of the
solutions to achieve this goal from the perspective of efficient use
of network resources.
RFC5654[1] defines the following requirements which are specific to
P2MP.
- Traffic-engineered point-to-multipoint (P2MP) transport paths.(item
6)
- Unidirectional point-to-multipoint transport paths (item 8)
- Being capable of using P2MP server (sub)layer capabilities when
supporting P2MP MPLS-TP transport paths(item 40)
- The MPLS-TP control plane MUST support establishing all the
connectivity patterns defined for the MPLS-TP data plane (i.e.
unidirectional P2MP) including configuration of protection functions
and any associated maintenance functions.(item 50)
Unidirectional 1+1 protection for P2MP connectivity (item 65 C)
- Unidirectional 1:n protection for P2MP connectivity(item 67 B)
- MPLS-TP recovery in a ring MUST protect unidirectional P2MP
transport paths.(item 95)
Koike, et al. Expires January 8, 2013 [Page 3]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
RFC5860[2] defines MPLS-TP OAM requirements including those for
unidirectional P2MP transport paths. In case of unidirectional P2MP
transport path, two cased are assumed as per section 3.3 of
RFC6371[3]. One is when an "out-of-band" return path exists and it is
used and the other is when any return path does not exist or is not
use. Missing OAM requirements which are necessary in P2MP transport
networks are those in the latter case.
In I-D[4], Operations, Administration and Maintenance (OAM) is
planned to be specified in clause 4. According to the editor's note,
this section will contain a summary of point-to-multipoint OAM as
described in RFC6371[3] that defines the overall OAM architecture for
MPLS-TP.
However, considering the missing OAM requirements in case that a
return paths don't exist, the most appropriate place where they could
be added is I-D[4]. Therefore, this draft intends to provide texts
which should be included in OAM section and network management
section of the I-D[4].
2. 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 [1].
2.1. Terminology
LSP Label Switched Path
2.2. Definitions
None
3. P2MP OAM
Note: It is proposed that this section be incorporated in section 4
of I-D[4].
Unidirectional P2MP is supported in MPLS-TP. This means that "in-
band" return path is out of scope. In this section, only two cases,
Koike, et al. Expires January 8, 2013 [Page 4]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
with out-band return path and without return path, are considered and
requirements should be independently specified, if necessary.
P2MP considerations are described in section 3.7 of RFC6371. The RFC
has already described some requirements with out-band return path(s).
On the other hand, even if there is no return path, parts of OAM
requirements in RFC5860 could be met by supporting management
interface through which EMS/NMS can retrieve the received OAM packets.
Note: In the following sections, basically additional requirements
are described function-by-function, which haven't been covered or
clarified in RFC5860[2] and RFC6371[3] have particularly focused on
the case that return paths doen't exist.
3.1. OAM functions for proactive monitoring
3.1.1. Continuity Check and Connectivity Verification
Continuity Check function enable one or more leaf MEPs on
unidirectional P2MP transport path to monitor the continuity of OAM
packets from root MEP and detect one or more loss of continuity(LOC)
defect between the root MEP and the leaf MEPs. Connectivity
Verification function enables one or more leaf MEPs on P2MP transport
path to monitor the connectivity of OAM packets from a specific root
MEP and detect an unexpected connectivity defect between two MEGs(two
P2MP transport paths)
Continuity Check and Connectivity Verification MUST be supported in
case that a return path in a unidirectional P2MP transport path
doesn't exist. This requirement is already included in section 2.2.3
of RFC5860[2].
As described in RFC6371[3], CC-V OAM packets are used for P2MP
transport path. Defect detection mechanisms in P2MP transport paths
are the same as those of P2MP transport path specified in section 5.1
of RFC6371. That is, loss of continuity defect, mis-connectivity
defect, period mis-configuration defect and unexpected encapsulation
defect. Entry criteria and exist criteria are also the same as those
of P2MP transport path in RFC6371[3]. Moreover, consequent actions of
unidirectional P2MP transport path are also covered in section 5.1.2
of the RFC[3]
Regarding configuration consideration, following additional
requirements on unidirectional P2MP transport path in case that the
return paths don't exist.
Koike, et al. Expires January 8, 2013 [Page 5]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
1. EMS/NMS should provide a tool to manually configure consistent
values on each piece of configuration information (MEG-ID, MEP-ID,
list of the other MEPs in the MEG, PHB for E-LSPs, transmission
rate) to a root-MEP and all the related leaf-MEPs in a MEG of a
P2MP transport path.
2. Mis-matches of configuration information (MEG-ID, MEP-ID, PHB for
E-LSPs, transmission rate) between a root MEP and any leaf-MEP at
which proactive monitoring is enabled, should be detected as a
configuration mis-match alarm by parsing received CC-VOAM packets.
3. Mis-matches of configuration information (MEG-ID, MEP-ID, list of
the other MEPs in the MEG, PHB for E-LSPs, transmission rate)
between a leaf MEP and any other leaf-MEP, at which proactive
monitoring are enabled, may be detected through configuration
management process of EMS/NMS as a configuration mis-match alarm
without receiving OAM packets from a source MEP.
4. Configuration information mis-match alarms described in 4 and 5
may be supported in case that a proactive monitoring is not
enabled in order to check those mis-matches before monitoring
functions are enabled.
5. Enabling or disabling configuration mis-matich alarms must be able
to be configured at each leaf-MEP independently.
3.1.2. Remote Defect Indication
This OAM function is not available on P2MP transport path in case
that return paths don't exist, because this function is implemented
only on the return path.
3.1.3. Alarm Reporting
Alarm Reporting functions MUST be supported in case that a return
path in a unidirectional P2MP transport paths don't exist. This is
already included in section 2.2.8 of RFC5860[2].
6. EMS/NMS should provide a tool to manually configure consistent
values on "hold-off intervals prior to asserting an alarm to the
management system" and AIS transmission period to all the leaf-
MEPs in a MEG of a P2MP transport path.
7. Mis-matches of configuration information (hold-off interval and
AIS transmission period) between a root MEP and any leaf-MEP at
which alarm reporting is enabled, should be detected as a
configuration mis-match alarm by parsing received AIS OAM packets.
Koike, et al. Expires January 8, 2013 [Page 6]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
8. Mis-matches of configuration information (hold-off interval and
AIS transmission period) between a leaf MEP and any other leaf-MEP,
at which alarm reporting is enabled, may be detected through
configuration management process of EMS/NMS as a configuration
mis-match alarm without receiving OAM packets from a source MEP.
9. Configuration information mis-match alarms described in 4 and 5
may be supported in case that a alarm reporting is not enabled in
order to check those mis-matches before monitoring functions are
enabled.
10.Enabling or disabling configuration information mis-matich alarms
must be able to be configured at each leaf-MEP independently.
3.1.4. Lock Reporting
FFS
3.1.5. Packet Loss Measurement
FFS
3.1.6. Packet Delay Measurement
FFS
3.1.7. Client Failure Indication
FFS
3.2. OAM functions for on-demand monitoring
3.2.1. Connectivity verification
Connectivity Verification function enables one or more leaf MEPs on
P2MP transport path to monitor the connectivity of OAM packets from a
specific root MEP and detect an unexpected connectivity defect
between two MEGs(two P2MP transport paths)
11.Connectivity verification functions MUST be supported in case that
return paths in a unidirectional P2MP transport path don't exist.
Koike, et al. Expires January 8, 2013 [Page 7]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
As described in RFC6371[3], CC-V OAM packets are used for P2MP
transport path. Defect detection mechanisms in P2MP transport paths
are the same as those of P2MP transport path specified in section 5.1
of RFC6371. That is, loss of continuity defect, mis-connectivity
defect, period mis-configuration defect and unexpected encapsulation
defect. Entry criteria and exist criteria are also the same as those
of P2MP transport path in RFC6371[3]. Moreover, consequent actions of
unidirectional P2MP transport path are also covered in section 5.1.2
of the RFC[3]
Regarding configuration consideration, following additional
requirements on unidirectional P2MP transport path in case that
return path doesn't exist.
12.EMS/NMS should provide a tool to manually configure consistent
values on each piece of configuration information (MEG-ID, MEP-ID,
list of the other MEPs in the MEG, PHB for E-LSPs, transmission
rate) to a root-MEP and all the related leaf-MEPs in a MEG of a
P2MP transport path.
13.Mis-matches of configuration information (MEG-ID, MEP-ID, PHB for
E-LSPs, transmission rate) between a root MEP and any leaf-MEP at
which proactive monitoring is enabled, should be detected as a
configuration mis-match alarm by parsing received CC-VOAM packets.
14.Mis-matches of configuration information (MEG-ID, MEP-ID, list of
the other MEPs in the MEG, PHB for E-LSPs, transmission rate)
between a leaf MEP and any other leaf-MEP, at which proactive
monitoring are enabled, may be detected through configuration
management process of EMS/NMS as a configuration mis-match alarm
without receiving OAM packets from a source MEP.
15.Configuration information mis-match alarms described in 4 and 5
may be supported in case that a proactive monitoring is not
enabled in order to check those mis-matches before monitoring
functions are enabled.
16.Enabling or disabling configuration mis-matich alarms must be able
to be configured at each leaf-MEP independently.
3.2.2. Packet loss measurement
FFS
Koike, et al. Expires January 8, 2013 [Page 8]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
3.2.3. Diagnostic tests
17.Diagnostic test functions MUST be supported in case that a return
path in a unidirectional P2MP transport path doesn't exist.
Other requirements are ffs.
3.2.4. Route Tracing
18.Route tracing function MUST be supported in case that a return
path in a unidirectional P2MP transport path doesn't exist.
Other requirements are ffs.
3.2.5. Packet delay measurement
FFS
3.3. OAM functions for administration control
3.3.1. Lock Instruct
FFS.
4. Security Considerations
This document does not by itself raise any particular security
considerations.
5. IANA Considerations
There are no IANA actions required by this draft.
6. References
6.1. Normative References
[1] Niven-Jenkins, B., et all, "Requirements of an MPLS Transport
Profile", RFC5654, September 2009
[2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", RFC5860, May 2010
Koike, et al. Expires January 8, 2013 [Page 9]
Internet-Draft MPLS-TP p2mp OAM framework July 2012
[3] Busi, I., Dave, A. , "Operations, Administration and
Maintenance Framework for MPLS-based Transport Networks ",
RFC6371, September 2011
[4] Frost, Dan.,et all, "A Framework for Point-to-Multipoint MPLS
in Transport Networks", draft-fbb-mpls-tp-p2mp-framework-04,
June 2012
6.2. Informative References
None
7. Acknowledgments
The author would like to thank all members (including MPLS-TP
steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
in ITU-T) involved in the definition and specification of MPLS
Transport Profile.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Takafumi Hamano
NTT
hamano.takafumi@lab.ntt.co.jp
Masatoshi Namiki
NTT
namiki.masatoshi@lab.ntt.co.jp
Yoshinori Koike
NTT
Email: koike.yoshinori@lab.ntt.co.jp
Koike, et al. Expires January 8, 2013 [Page 10]