MPLS Japan 2013

Carrier Ethernet 技術は今…

2013/10/29
栃尾 祐治(富士通研究所)
MPLS Japan 2013

発表に至った背景
 昭和の高度経済成長を支えた三種の神器…

2MPLS Japan 2013

時代は繰り返し…
 つい最近(2007年前後)、Carrier Ethernet がまだブームだったころ
この分野にも三種の神器があったらしい…
 PBB (Provider Backbone Bridge) – IEEE802.1ah
 Ethernet Ring Protection – ITU-T G.8032

 Ethernet OAM (S-OAM) – IEEE802.1ag / ITU-T Y.1731

注: IEEE802.1ag, 802.1ah は、IEEE802.1Q-2005 のAmendment であり、今は IEEE802.1Q-2011の一部として記述されています
3

MPLS Japan 2013

ここから本題 - 本日お話しすること
 一言でいうと ITU-T, IEEE, MEF (Metro Ethernet Forum) を中心とした最近のCarrier Ethernet 向けの標準化技術のお話です MPLSは… (ぼそ)

 その中で、先の三種の神器に注目して、今どう進化(!)または衰退(?)したかをざっと紹介するとともに、その背後の理由も分析• PBB (Provider Backbone Bridge) … ??
• Ethernet Ring Protection … !?
• Ethernet OAM … !!

 これだけではつまらないので、SDNネタも少しいれておきました  ご注意：本発表は標準化動向に基づく客観的情報または個人の見解を示すもので、会社の方針・戦略・意向等を示すものではありませんので、あらかじめご了承ください _ _4

MPLS Japan 2013

PBB (Provider Backbone Bridge)
 導入の経緯 Ethernet 網の大規模化(スケール)またはVLAN 4096の限界打破

 導入したもの
 MAC-in-MAC の導入

PB装置PB(Q-in-Q)

 I-SID (24bits)の定義

PB装置

PB
装置

PBB
装置

PBB

PBB
装置

PB
装置

PB装置

PB
装置

PB network frame format

DA

S-tag

C-tag
(option)Data, FCS

DA & SA

S-tag(option)C-tag(option)Data, FCS

DA & SA

S-tag(option)C-tag(option)Data, FCS

SA

TPID

B-tag frame format

B-DA

B-SA

SVID

互換性維持

B-tag
TPID

I-tag
BVID

TPID

I-SID

TPID

I-SID

I-tag frame format

B-DA

B-SA

I-tag

5

MPLS Japan 2013

PBB (Provider Backbone Bridge)
 現状
 MAC-in-MAC なネットワーク構成は確かに導入されたが、I-SID とは異なるフォーマットかつ、802.1ad とは異なるフォワーディング手法が主流に？
 フォーマット観点• TRILL: Ingress / Egress RBridge Nickname 使用• VXLAN, NVGRE: IP + UDP/GREヘッダ+ 24bits 識別子• 他、MPLS Big/Mega label, VPLS (EVPN含む)など MPLS
B-DA

PBB

B-SA

B-tag
TPID

TRILL

VXLAN

B-DA

B-DA

B-SA

B-SA
B-tag
TPID

NVGRE

B-DA

B-SA

BVID

B-tag
TPID

BVID

TPID

BVID

B-tag
TPID

I-tag

BVID

IP header
TPID IPv4/v6

IP header
TPID IPv4/v6

I-SID

Data, FCS
C-DA & C-SAC-DA &C-SA

Data, FCSUDP VXLANC-DA &C-SA

Data, FCSGRE TenantID

C-DA &C-SA

Data, FCS

Trill header
TPID

RB

 フォワーディング観点• TRILL, SPB に見られるMAC address base のものは存在するが、NVGREなど IP 依存のものも存在 ( IETF NVO3立ち上げも一動機)
6

MPLS Japan 2013

PBB (Provider Backbone Bridge) 分析(反省点)


難解なB-MAC の学習方式

C-SA

C-DA

B-DA

B-SA をベースに
C-SAを学習

C-DAをキーに、B-DA 割出し

B-SA

B-tag
I-SID

C-SA

C-DA

C-DA

B-tag
I-SID

C-SA

B-SA

B-DA

 明確にしなかった(できなかった) I-SID の決定方式• I-SIDの決定方式はあくまでユーザー任せ
OF wire protocol でも I-tag は扱えても、I-SIDは…

• I-SID単位でのOAMアーキテクチャの不完全さ• 一方で、I-SIDでのソリューションを定義する IETF L2VPN ドラフト (PBB-EVPNなど)
 コア内の運用管理• 原則、B-MAC & B-VIDだけでフォワードする方式に対して運用への不安• 例えば、- コア内(PBB網内)で、I-SIDに基づいてフォワーデングドメインを切って転送してほしいという顧客の声 (つまりコア内接続全てに I-tag IFを設けたい)- Trill だけでなく、SPB (Shortest path bridge) に見られるような方式の提案
7

All Right Reserved, Copyright FUJITSU LIMITED 2005

Ethernet Ring Protection (ERP) ITU-T におけるEthernet Protection 勧告
 G.8031: Ethernet Linear Protection• 2006年に初版発行、SDH などで適用した APS を採用
 G.8032: Ethernet Ring Protection• 2006年ごろから勧告化の作業開始、2008年に初版発行し最新版は2012年• 今後、原則大きな更新は行わないことが確認された
 G.sup52: Ethernet ring protection switching• 補遺文書。正式な勧告ではない• G.8032を適用した様々なアプリケーションの記載
E-line/E-LAN/E-Tree over G.8032
マルチリングの適用例
G.8031 over G.8032 (右図)

KL

JCA

E

Sub-ring

Sub-ring

Major ring

DB

F
M

H
G
G.8032-Y.1344(12)_FXI.2

 蛇足G.808.3: Generic protection switching - Shared mesh protection• Shared mesh protection に関するプロトコル中立な勧告。2012年発行• 現在、ODU(OTN)についてはITU-Tで議論進行中。MPLS-TPはIETFに要求文書が存在 (draft-ietf-mpls-smp-requirements)
 ということで、ITU-T で目新しい活動はない、、、？
8All Right Reserved, Copyright FUJITSU LIMITED 2005

New work in ITU-T - MDSP Multi-domain Segmented Network Protection

つい最近までは、Protection Interworking とも呼んでいた

 タイトル通り、複数のドメイン上にまたがる End-to-end サービスの冗長技術の提供として、既存プロテクション技術の相互接続のシナリオをまとめたもの
 相互接続の形態
Single node InterconnectDual node Interconnect問題(議論)となるケースはDNIの方9All Right Reserved, Copyright FUJITSU LIMITED 2005

MDSP – Hot topics
 DNI case for Ethernet(ETH)-ETH MDSP

このケースにおいて、どういう既存プロテクションケースが実現できるのか？
Ethernet protected domain

Ethernet protected domain

l1l2

ETHETH(G.8031/G.8032)(G.8031/G.8032)
l4

l3

Segment protection 1

Segment protection 2

End-to-end service survivability

とりあえず、G.8032 だけであれば実現可能であるが、、、

10

MPLS Japan 2013

MDSP – Hot topics
 DNI case for ETH-ETH MDSP を通して出てきた話題(課題)ENNI(赤枠内)へのIEEE802.1AXbq (DRNI) の考慮• DRNI(Distributed Resilient Network Interconnect): 802.1AX(LAG)9章として追記作成中• 複数システム間でのLAG 提供により、 DNI に適用可能になるが そのDRNIとのInterworking をどう考えるか (現時点では、将来の課題としてペンディング状態)

Linear protection 拡張としての DNI Protection. すなわち Dual homing サポート
• これもまたペンディング状態。ただDNI protection 勧告化の期待は高まりつつあり

11

MPLS Japan 2013

参考: DNI Protection の現状
 今回の件に限らず、似て非なるソリューションが
 PWE3 WG• draft-ietf-pwe3-iccp-12 (Inter-Chassis Communication Protocol for L2VPN PERedundancy) など
 L2VPN WG• draft-ietf-l2vpn-vpls-multihoming, EVPN 関連など
 CCAMP WG (参考)• http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-03
 他、MC-LAG など

 あまりにプロプラな技術が存在する中、標準化に価値があるのか？ その点は、よく考える必要はある

12

MPLS Japan 2013

Ethernet OAM (G.8013/Y.1731)変遷
 最新版(2013年版)におけるサポート機能 (黄色マーカー部が初版からの追加)
大きな更新は、Performance measurement 機能 (LM, DM, SL) 背景には MEF からの強い要望も含まれる (MEF 35など)
ClassPro-active

Type
StatusPerformance

MaintenanceOn-demand

StatusPerformance

Fault localization

ProtectionDiscovery
Communication channel

General purpose Communication channel
Experimental
Vendor specificFunction
Continuity check & Connectivity verification
Interruption
Frame loss
Synthetic frame loss
Frame delay
Alarm suppression
Locked indication
Remote defect indication
Client signal failConnectivity check
Frame loss
Synthetic frame loss
Frame delay
Throughput
Channel connectivity
Flow connectivity
Flow connectivity
State machine synchronization (APS)Management communication channel

13

OAM frames
CCM.CC
CCM.CC, CCM.RDI
CCM.LM, LMM/R
SLM/R, 1SL
DMM/R, 1DM
AIS
LCK
CCM.RDI
CSF
LBM/R
LMM/R
SLM/R, 1SL
DMM/R, 1DM
TST, LBM/R
LBM/R
LTM/R
LTM/R
Linear APS (G.8031)
Ring APS (G.8032)
MCC
EXM/R
VSM/R

All Right Reserved, Copyright FUJITSU LIMITED 2005

参考: MEF 35 とは Service OAM Performance Monitoring Implementation Agreement (主に北米の)キャリア要求と、PM 向けツール(i.e Y.1731)ならびに MEF サービ
ス規定を前提にPM ソリューション規定を紹介
 Ethernet サービス提供に当たって、Performance 規定は重要な属性
 資料は http://metroethernetforum.org/carrier-ethernet/technical-specifications から入手可能

以下は、http://metroethernetforum.org/Assets/Technical_Specifications/PPT/Overview-of-MEF-35.pptx から抜粋

PMSolution
PM-1

MEG
Type(s)point-to-point
multipoint

Measurement Techniquefor Loss
Synthetic
Testing

PM Function(s)Mandatory or
Optional
Mandatory

Single-Ended Delay
Single-Ended Synthetic Loss

PM-2

point-to-point
multipointn/a

Dual-Ended Delay

Optional

PM-3

point-to-point

Counting Service Frames

Single-Ended Service Loss

Optional

PM Function

ITU-T PM Tool

ITU-T PDU(s)Single-Ended Delay

ITU-T Two-way ETH-DM

DMM/DMR

Dual-Ended Delay

ITU-T One-way ETH-DM

1DM

Single-Ended Service Loss

ITU-T Single-Ended ETH-LM
http://metroethernetforum.org/carrierITU-T Single-Ended ETH-SLM
ethernet/technical-specifications

LMM/LMR

Single-Ended Synthetic Loss

14

SLM/SLR

MPLS Japan 2013

G.8013/Y.1731 – PM update SLM (Synthetic Loss measurement)
1815913172125:
last

Source MEP ID& responder ID

Sequence counter (の演算)によるLoss measurement76524MEL

321876534321876Version (0)OpCode (SLM = 55)
Source MEP ID

45432187654321Flags (0)TLV Offset
Reserved for Responder MEP ID (0)Test ID
TxFCf
Reserved for SLR: TxFCb (0)[Optional TLVs start here, otherwise End TLV]

identifying an uniquetest among MEPs
(ID識別で on-demand/proactiveをも識別)End TLV (0) DMMv1 (Proactive 対応)
181
5913172125
29333741
45
:
last

76MEL

52
432

1Version (1)87653432

1876

OpCode (DMM=47)

5Data TLV 定義(フレーム長定義)

44(p2mpの対応でSLMにだけ定義)

32Flags

18765432TLV Offset (32)

TxTimeStampf

1On demand
On-demand/Proactive
識別flag定義
識別flagReserved for DMM receiving equipment (0)(for RxTimeStampf)
Reserved for DMR (0)Test ID TLV
Data TLV 定義(後者はフレーム長定義するケースに備えたもの)(for TxTimeStampb)
Reserved for DMR receiving equipment (0)[optional TLV starts here; otherwise End TLV]End TLV (0)15

MPLS Japan 2013

G.8013/Y.1731 – PM update
 LMMv1 (Proactive 対応)
1815913
177 6MEL

54 3 2 1Version (1)827 6 5 4 3 2OpCode (LMM=43)

187635 4Flags

3TxFCfReserved for RxFCf in LMRReserved for TxFCb in LMR

218746 5 4 3 2
TLV Offset (12)1On-demand/Proactive
識別 flag

End TLV (0) LMM proactive 導入でややこしくなったのが、(該当 MEL 上にある)OAM frameのカウント条件
On-demand LM 運用時 (既存):
On demand OAM はカウントしない一方で、Proactive (CC, APS, CSFなど) はカウントする
 Proactive LM (LMM/R) 運用時 (新規):
APS, CSF, CCM はカウント。その他の Proactive OAM (Proactive DM など)はカウントしない Proactive LM (CCM) 運用時 (既存):APS, CSF のみカウントその他OAMはカウントしない
16

MPLS Japan 2013

Ethernet OAM 関連補足 – G.8052
 本末転倒な補足()として ITU-T G.8052 について
 Protocol-neutral management information model for the Ethernet
Transport network element 2013/08 承認 (作業開始から完成まで8年以上！)注: 正式公開まではもう少し時間がかかります。メンバであれば最新ドラフトは参照可能

 EMS-NE間に適用される管理インタフェース規定
 ITU-T 規定のネットワーク装置(NE)、つまりEthernet では
G.8021 をベースに作成した装置規定に基づき、M.3160
規定の管理情報モデルに従い モデル化したもの
 平たくいうと、G.8021 の管理インタフェース(MI)をUML表記し、 Protocol-neutral に規定

GUINMS

serverGUI

 拡張例: MEF38&39 (S-OAM YANG Module),
MEF40 (UNI and EVC Managed Object - SNMP) LAG, Protection (G.8031, G.8032)など、G.8021 に書いてあるものすべて対象にしたため、完成まで時間を要したが、特に、作業工数を要したのが OAMに関わるモデル化(Object Class diagram)
17client

interface

EMS

client

G.8052interfaceserver
LCTNE

MPLS Japan 2013

G.8052 - OAM アーキのモデル(UML)化
Cross Connection(CC))

 OAM Architecture (ME階層込)ETH TTPETH/
ClientClient Layer CTP

G.8021 モデル(Connection,Flow Termination, Adaptation)を
G.8052 Object class に変換

sublayerboundary

ETH
NCM
MEP

ETHD/
ETH
ETHDe

ETH/
ETH

ETHG/
ETH

ETH

ETHG
TCM
MEP

6x

MIP

Group
MIP

ETHDi

ETHDi

ETHD/
ETH

ETHD/
ETH

at mostone
TCM
Group
MEP

ETHD/
ETH

ETHD/
ETH

ETHD/
ETH

ETHD/
ETH

ETHDe

ETHDe

ETHDi

ETHDi

ETHx
Sublayer

onlytagged
layersTCS

Trail Termination
Point (TTP)+ MEP & MIP+ TCS(Traffic conditioning)CC
CTP Pool

Connection
Termination
Point (CTP)

CTP Pool

ETH CTP(s)
ETH/
ETH-m

ETH TTP

sublayerboundary

ETH
NCM
MEP

ETHD/
ETH
ETHDe

ETH/
ETH

ETHG/
ETH

ETH

ETHG
TCM
MEP

6x
CC

MIP

Group
MIP

ETHDi

ETHDi

ETHD/
ETH

ETHD/
ETH

at mostone
TCM
MEP

ETHD/
ETH

ETHD/
ETH

ETHD/
ETH

ETHD/
ETH

ETHDe

ETHDe

ETHDi

ETHDi

CTP Pool

ETHx
Sublayeronlytaggedlayers
TCS

CTP Pool

ETH CTP(s)ETH TTP

ETH/
ETH-m

sublayerboundary

ETH
NCM
MEP

ETHD/
ETH
ETHDe

ETHDi
at mostone

ETH
CC
6x

ETHx
Sublayer

MIP

ETH/
ETH

TCM
MEP

ETHD/
ETH

ETHD/
ETH

ETHD/
ETH

ETHDe

ETHDi

onlytagged
layersTCS

ETH CTP(s)<SRV>/ETH<SRV>

sublayerboundary

お断り: 図内の字が細かく見づらいと思いますが詳細は勧告をご参照下さい

Server Layer TTP
Containment (user frame flow)
Pointer association (user frame flow)
Containment of auxiliary objects for OAM

18

MPLS Japan 2013

G.8052 - OAM アーキのモデル(UML)化お断り: 図内の字が細かく見づらいと思いますが詳細は勧告をご参照下さい

 MEP on-demand Diagnostic Functionの例
ETHx/
ETH
ETHx

MI_XXX
MI_YYY…

Proactive

MEP
ETHD/
ETH

ETHD

On-demand

Object Class Diagram(On-demand Measurement)

Measurement andMaintenanceMI list (G.8021)

MEP Control
TTP
CTP

TTP SoEMS

MEP(Bidir)

EMS

maintenanceEntityGroupEndPointBidirectional

CTP Skatomic functions

On-demand

establishOnDemand2-WayMeasurementJob()
creates

Measurement
JobControl

CTP SoAtomic Function(i.e NE)

On-demand
2way

TTP SkOnDemand2-WayMeasurementJobControl
object createdObject Creation Notification

MEP Source Measurement
MEP(Bidir)

getIntermediateReport()
Intermediate request ()Result ()Intermediate Report Return

1way So

2way

abortOnDemandMeasurementJob()
deletes

MEP Sink

Job control

at start time -> Start ()1way Sk

Terminate ()Measurement Interval

object deleted
Object Deletion Notificationor
at stop time -> Terminate ()Result ()PM Report Notification

object deleted

Sequence List

Object Deletion Notification

Data Dictionary
19

MPLS Japan 2013まとめ
 最近のCarrier Ethernet 動向として、三種の神器(?)だった３つの技術について近況分析を紹介
 PBB
Overlayを考慮したフォワーディングに未だWinnerなし? それとも Divergenceの時代なのか?
 その中で特に考慮しないといけないもの: Address に基づく転送
 Ethernet Ring Protection
基本的な動作は完成、あとはどう使い込んで行くか 課題: DNI protection – 標準化にしますかそれとも??
 Ethernet OAM (S-OAM)
PM についてドラスティックに拡張。この先どう使いこなして行くかが課題
 他、この先、必要なOAM toolがないか? よく考えて行きたい• 実はG.8013/Y.1731向け OpCode が殆ど残ってません (残り9つ (実質4つ)) SDN 時代に重要となる(はずの) Info Model にも着手

 細々ですが、標準化に向けた検討はまだまだ進んでいますし、まだまだ、考えるべきことあります！
20

MPLS Japan 2013

ありがとうございました