IETF84
A framework for Point-to-Multipoint
MPLS-TP OAM in case that return paths
don’t exist
draft-hmk-mpls-tp-p2mp-oam-framework.txt
August 3, 2012
Yoshinori Koike
Takafumi Hamano
Masatoshi Namiki
Background
 Demand for P2MP traffic is expected to
increase due to the increase in new services
such as IP-TV and video distribution services.
 P2MP is also important in terms of energy
efficiency and efficient network resource
usage
Agreement in ITU-T to support moving
forward p2mp
https://datatracker.ietf.org/liaison/1163/
Motivation
• Inputs to develop MPLS-TP p2mp framework
draft(draft-fbb-mpls-tp-p2mp-framework).
• As a fast step, focusing on the case of no
return path, assuming that OAM is applied on
p2mp transport path in conjunction with
EMS/NMS
OAM functional requirements in MPLS-TP (RFC5860)
 OAM functions are one of the most important key requirements
in transport networks
OAM functional
requirement
Function
Contents
1
Continuity Checks
CC
Monitor liveliness of transport path
2
Connectivity
Verifications
CV
Determine whether or not it is connected to specific end
point(s) of transport path
3
Route Tracing
RT
Discover intermediate (if any) and end point(s) along transport path
4
Diagnostic
Tests
DT
Conduct diagnostic tests on transport path
(estimating bandwidth, performing loop-back (LB) function of all data and OAM traffic
(data-plan LB))
5
Lock Instruct
LI
Instruct its associated end point(s) to lock transport path
6
Lock Reporting
LR
Report lock condition from intermediate point to end point of transport path
7
Alarm
Reporting
AR
Report fault or defect condition to end point of transport path
8
Remote Defect
Indication
RDI
Report fault or defect condition to its associated end
point
9
Client Failure
Indication
CFI
Propagate information pertaining to client defect or fault condition
10
Packet Loss
Measurement
LM
Quantify packet loss ratio over transport path
11
Packet Delay
Measurement
DM
Quantify delay of transport path (1-way and 2-way)
First step: in case of no return path
First step: Specify requirements, that is necessary information
to manage p2mp transport path in case of no return path
1) OAM functions with EMS/NMS
Report from
target MEP
EMS/NMS
2) OAM functions with return paths
to originating MEP
Out-of-band
return path
G
G
D
D
H
B
H
B
A
E
A
C
In-band
OAM
packets
F
I
E
C
F
I
J
J
Issues on p2mp OAM requirements(RFC5860)
Even if no return path exists, OAM requirements should be
achieved in conjunction with EMS/NMS on CV, RT and DT.
OAM
functions
(RFC5860)
CC
CV
Proactive P2MP
On-demand P2MP
Proposed requirements for ondemand P2MP
YES
YES
NA
YES
RT
NO
DT
NO
LI
NO
LR
AR
RDI
YES
YES
YES
(in case a return path exists)
YES
YES
YES
(only to enable the
quantification of the one-way
delay)
NA
YES
(in case a return path exists)
YES
(in case a return path exists)
YES
(in case a return path exists)
YES
(in case a return path exists)
NA
NA
NA
NA
YES
YES
(only to enable the
quantification of the one-way
delay)
NA
- (Already supported)
- (Already supported)
CFI
LM
DM
YES
YES
NO
NA
NA
NA
Next steps
• Identify what are covered in other RFCs and what are
missing as p2mp framework
• Specify necessary OAM information/monitored items
to be managed at targeting nodes(MEPs) based on
the case in which no return path exist
• Specify necessary OAM information at source
node(MEP) or bud nodes(MIPs) based on the case in
which return path exist
• Incorporate contents into draft-fbb-mpls-tp-p2mpframework as needed
Thank you