Ethernet OAM study in ITU-T SG13
Hiroshi Ohta, NTT
ITU-T SG13 Q.3/13 rapporteur
November 11, 2003
November 11, Albuquerque
1
ITU-T SG13, Q.3/13: current status
 Objectives: OAM and network management
 Consented Y.1730 (ETH OAM reqs)
 To be approved after last call/comment resolution
 OAM mechanism (Y.17ethoam)
 Physical layer OAM reqs (Y.17etyreq)
 MPLS related Recommendations (revised
Y.1711: MPLS OAM, revised Y.1720: MPLS
protection switching, Y.1712: interworking
OAM) were also consented
November 11, Albuquerque
2
Q.3/13 meets next week (interim meetig)
 Y.17ethreq (OAM requirements): under
comment resolution of LC
 Can be an input for IEEE 802.1 OAM
development
 Y.17ethoam (Ethernet OAM mechanism)
 Can be an input for IEEE 802.1 OAM
development
 Y.17etyreq (Physical layer OAM requirements)
 For information for IEEE 802.1/.3
November 11, Albuquerque
3
How to cooperate?
 IEEE 802 takes “bottom up” approach
 Starts from mechanism
 ITU-T takes “top down” approach
 Starts from requirements
 How about …
 Detailed specifications by IEEE 802.1
 Requirements and description (application) by
ITU-T SG13
 ITU-T SG13, Q.3/13 meets next week. Q.3/13
will send the resulted draft to IEEE 802
November 11, Albuquerque
4
Ethernet OAM requirements: Y.1730
 Reference network model: EPL, EVPL, EPLAN
and EVPLAN (point-to-point and multipoint)
 Aligned with ITU-T SG15 (G.8010 (ex. G.ethna),
G.8011 (ex. G.ethsrv))
 Motivation and general requirements
 Maintenance entity (segment/domain)
 Necessary OAM functions
November 11, Albuquerque
5
Necessary OAM functions







Continuous connectivity check (CC)
Alarm suppression function
Loopback
Path trace
Discovery
Performance monitoring
Survivability function (e.g., protection switching,
restoration, etc.)
 Detailed mechanisms are covered by
Y.17ethoam
November 11, Albuquerque
6
OAM segment/domain
 Customer UNI-UNI
 Provider UNI-UNI
 Segment OAM:A segment may be:
 Between flow points on the boundary of a
providers network
 Between flow points on the boundaries of
two adjacent provider networks
 Between any flow points as required
 ETY link connection OAM
November 11, Albuquerque
7
Ethernet OAM mechanism
 Draft Recommendation Y.17ethoam
 OAM mechanism: segment/domain, functions
(continuous connectivity verification, alarm
suppression, loopback, path trace, discovery,
performance management, survivability)
 Several companies brought their proposals in
July meeting: Cisco, Fujitsu, Hitachi, Nortel,
PMC-Sierra
 To be discussed further in the next interim
meeting next week (17-21 November in
Geneva)
November 11, Albuquerque
8
Ethernet PHY OAM Requirements
 Draft Recommendation Y.17etyreq
 Initiated in July meeting
 Reference networks: access networks (with
OLT/ONT) and core networks (with repeaters)
 To be discussed further in the next interim
meeting (17-21 November in Geneva)
November 11, Albuquerque
9
ETY OAM ref network: access
OSS (Operation
Support System)
Ether transport
network A
CE
ONT
OLT
MAC
PHY
PE
PE
MAC
PHY
November 11, Albuquerque
PHY
PHY
10
ETY OAM ref network: core
OSS (Operation
Support System)
PE
REP
REP
REP
REP P/PE
MAC
PHY
MAC
PHY
November 11, Albuquerque
PHY
PHY
PHY
PHY
11
ETH architecture/service: ITU-T SG15
 G.8010 (ex. G.ethna): ETH architecture
 Consented at the last SG15 meeting
 G.8011 (ex. G.ethsrv): ETH services
 To be consented at the next SG15 meeting (April
2004)
November 11, Albuquerque
12
Summary and next steps
 Within ITU-T,
 Ethernet OAM in ITU-T SG13
 Ethernet architecture/service in ITU-T SG15
 Collaborative work between IEEE 802.1,
802.3ah, MEF, ITU-T SG13/SG15 is necessary
 Consistent development of standards on
Ethernet network architecture, services and
OAM is essential
 Comments, suggestions, contributions are
welcome.
November 11, Albuquerque
13
Backup
November 11, Albuquerque
14
EPL and EVPL: Line services (1)
D
A
ETH/
client
ETH/
client
ETH trail
ETH AP
ETH AP
ETH
FT
B
ETH TFP
ETY/
ETH
ETH
LF
ETH
LF
ETH FP
ETY/
ETH
ETY
Trail
ETH
LF
ETH FP
S/
ETH
S/
ETH
ETY/
ETH
S
TT
S
TT
ETY NC
ETH
FT
ETH TFP
ETY/
ETH
ETY
Trail
S trail
ETY
TT
ETY
TT
C
ETY
TT
ETY
TT
ETY NC
UNI
UNI
NNI
November 11, Albuquerque
15
EPL and EVPL: Line services (2)
E
A
ETH/
client
ETH/
client
ETH trail
ETH AP
ETH AP
ETH
FT
ETH TFP
ETY/
ETH
ETY
TT
ETH
LF
ETY
Trail
ETY
NC
ETH
LF
ETH FP
ETY/
ETH
ETY
TT
S/
ETH
S
TT
ETH
LF
ETH FP
S/
ETH
S
Trail
S
TT
Z/
ETH
Z
TT
ETH
LF
ETH FP
Z/
ETH
Z
Trail
Z
TT
UNI
ETY/
ETH
ETH TFP
ETY/
ETH
ETY
Trail
ETY
TT
ETY
TT
UNI
NNI
November 11, Albuquerque
ETH
FT
D
C
B
NNI
16
EPLAN and EVPLAN: LAN services
Provider
Network (=FD)
B
H
FP
J
FP
A
FP
FP
TFP
G
FP
FP
FP
FP
FP
I
FP
E
TFP
FP
FP
C
November 11, Albuquerque
TFP
FP
TFP
FP
TFP
TFP
F
FP
D
TFP
17
General requirements (1)
 Support of client/server OAM relationships
between Ethernet and its server layers
 On-demand and continuous connectivity
verification
 Detection, diagnostics, localisation, notification
to network management systems
 Customers should not have to detect failures.
 Ethernet OAM frames should be forwarded on
the same route as the user ETH flow is
forwarded.
November 11, Albuquerque
18
General requirements (2)
 Defects to be detected:
 simple loss of connectivity
 unintended self-replication (e.g., looping,
denial of service (DoS) attack).
 Lost/errored frames
 misinserted frames (e.g., misinsertion of a
frame into unintended VLANs)
 Alarm suppression for server layer sourced
defects.
 OAM functions should be simple and easily
configured (ideally automatically)
November 11, Albuquerque
19
General requirements (3)
 OAM functions should be optional
 Ethernet OAM functions should be backward
compatible.
 Capability to measure availability and network
performance
 Ethernet OAM should be independent on any
specific server or client-layer network.
 Ethernet OAM flow should be sufficiently
independent of any specific control-plane
November 11, Albuquerque
20
General requirements (4)
 Connectivity status assessment should not be
dependent on the dynamic behaviour of
customer traffic.
 The OAM function should perform reliably even
under degraded link conditions, e.g., error
events.
 The operator that offers the service should be
aware of a service fault in the network of
another operator.
 The “down” time of the service should be able to
be recorded for performance and availability
measurements.
November 11, Albuquerque
21