1/4C000 l 120m - Yukuhashi...工事年度 工事 名 工事箇所 図面 名 縮尺 事務所名 当 回変更 初 可 第 認 実 施 当 第 回変更 初 査定 図面番号 全
MPLS Japan 2013 Carrier Ethernet 技術は今… · •2006年に初版発行、SDH...
21
2013/10/29 栃尾 祐治(富士通研究所) MPLS Japan 2013 Carrier Ethernet 技術は今… MPLS Japan 2013
Transcript of MPLS Japan 2013 Carrier Ethernet 技術は今… · •2006年に初版発行、SDH...
2013/10/29
栃尾 祐治(富士通研究所)
MPLS Japan 2013
Carrier Ethernet 技術は今…
MPLS Japan 2013
発表に至った背景
昭和の高度経済成長を支えた三種の神器…
MPLS Japan 2013
2
時代は繰り返し…
つい最近(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の一部として記述されています
MPLS Japan 2013 3
ここから本題 - 本日お話しすること
一言でいうと ITU-T, IEEE, MEF (Metro Ethernet Forum) を中心とした最近のCarrier Ethernet 向けの標準化技術のお話です
MPLSは… (ぼそ)
その中で、先の三種の神器に注目して、今どう進化(!)または衰退(?)したかをざっと紹介するとともに、その背後の理由も分析
• PBB (Provider Backbone Bridge) … ??
• Ethernet Ring Protection … !?
• Ethernet OAM … !!
これだけではつまらないので、SDNネタも少しいれておきました
ご注意：本発表は標準化動向に基づく客観的情報または個人の見解を示すもので、会社の方針・戦略・意向等を示すものではありませんので、あらかじめご了承ください _ _
MPLS Japan 2013 4
PBB (Provider Backbone Bridge)
導入の経緯
Ethernet 網の大規模化(スケール)またはVLAN 4096の限界打破
導入したもの
MAC-in-MAC の導入
I-SID (24bits)の定義
MPLS Japan 2013 5
B-DA B-SA B-tag I-tag
TPID TPID BVID I-SID DA & SA
S-tag
(option)
C-tag
(option) Data, FCS
B-DA B-SA I-tag
TPID I-SID
S-tag
(option)
C-tag
(option) Data, FCS DA & SA
I-tag frame format
B-tag frame format
DA SA S-tag
TPID SVID
C-tag
(option) Data, FCS
PB network frame format
互換性維持
PB (Q-in-Q)
PBB
装置 PBB PBB
装置
PB
装置
PB
装置
PB
装置
PB
装置
PB
装置
PB
装置
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
フォワーディング観点
• TRILL, SPB に見られるMAC address base のものは存在するが、NVGREなど IP 依存のものも存在 ( IETF NVO3立ち上げも一動機)
MPLS Japan 2013 6
B-DA B-SA B-tag
TPID BVID Data, FCS
C-DA &
C-SA
Trill header
TPID RB
Data, FCS IP header
TPID IPv4/v6
C-DA &
C-SA UDP VXLAN
B-DA B-SA B-tag I-tag
TPID TPID BVID I-SID C-DA & C-SA Data, FCS
B-DA B-SA B-tag
TPID BVID
Data, FCS IP header
TPID IPv4/v6
C-DA &
C-SA GRE TenantID B-DA B-SA
B-tag
TPID BVID
TRILL
PBB
VXLAN
NVGRE
PBB (Provider Backbone Bridge)
分析(反省点) 難解なB-MAC の学習方式
明確にしなかった(できなかった) 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) に見られるような方式の提案
All Right Reserved, Copyright FUJITSU LIMITED 2005 7
B-DA B-SA C-DA C-SA B-tag
I-SID B-SA をベースに
C-SAを学習
B-DA C-SA C-DA B-SA B-tag
I-SID
C-DA C-SA
C-DAをキーに、B-DA 割出し
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 (右図)
蛇足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 で目新しい活動はない、、、？
All Right Reserved, Copyright FUJITSU LIMITED 2005 8
G.8032-Y.1344(12)_FXI.2
L
M
G
J
H
K
A BMajor ringSub-ring Sub-ring
C E
D F
New work in ITU-T - MDSP
Multi-domain Segmented Network Protection
つい最近までは、Protection Interworking とも呼んでいた
タイトル通り、複数のドメイン上にまたがる End-to-end サービスの冗長技術の提供として、既存プロテクション技術の相互接続のシナリオをまとめたもの
相互接続の形態
Single node Interconnect
Dual node Interconnect
問題(議論)となるケースはDNIの方
All Right Reserved, Copyright FUJITSU LIMITED 2005 9
MDSP – Hot topics
DNI case for Ethernet(ETH)-ETH MDSP
このケースにおいて、どういう既存プロテクションケースが実現できるのか？
とりあえず、G.8032 だけであれば実現可能であるが、、、
MPLS Japan 2013 10
Segment protection 1 Segment protection 2
End-to-end service survivability
ETH(G.8031/G.8032)
Ethernet protected domain
ETH(G.8031/G.8032)
l1 l2
Ethernet protected domain
l3 l4
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 勧告化の期待は高まりつつあり
MPLS Japan 2013 11
参考: DNI Protection の現状
今回の件に限らず、似て非なるソリューションが
PWE3 WG
• draft-ietf-pwe3-iccp-12 (Inter-Chassis Communication Protocol for L2VPN PE
Redundancy) など
L2VPN WG
• draft-ietf-l2vpn-vpls-multihoming, EVPN 関連など
CCAMP WG (参考)
• http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-03
他、MC-LAG など
あまりにプロプラな技術が存在する中、標準化に価値があるのか？ その点は、よく考える必要はある
MPLS Japan 2013 12
Ethernet OAM (G.8013/Y.1731)変遷
最新版(2013年版)におけるサポート機能 (黄色マーカー部が初版からの追加)
大きな更新は、Performance measurement 機能 (LM, DM, SL)
背景には MEF からの強い要望も含まれる (MEF 35など)
All Right Reserved, Copyright FUJITSU LIMITED 2005 13
Class Type Function OAM frames
Pro-active Status Continuity check & Connectivity verification CCM.CC
Performance Interruption CCM.CC, CCM.RDI
Frame loss CCM.LM, LMM/R
Synthetic frame loss SLM/R, 1SL
Frame delay DMM/R, 1DM
Maintenance Alarm suppression AIS
Locked indication LCK
Remote defect indication CCM.RDI
Client signal fail CSF
On-demand Status Connectivity check LBM/R
Performance Frame loss LMM/R
Synthetic frame loss SLM/R, 1SL
Frame delay DMM/R, 1DM
Throughput TST, LBM/R
Fault localization Channel connectivity LBM/R
Flow connectivity LTM/R
Discovery Flow connectivity LTM/R
Protection Communication channel State machine synchronization (APS) Linear APS (G.8031)
Ring APS (G.8032)
General purpose Communication channel Management communication channel MCC
Experimental EXM/R
Vendor specific VSM/R
参考: 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 から抜粋
14
http://metroethernetforum.org/carrier-
ethernet/technical-specifications
PM
Solution
MEG
Type(s)
Measurement Technique
for Loss
PM Function(s) Mandatory or
Optional
PM-1 point-to-point
multipoint
Synthetic
Testing
Single-Ended Delay
Single-Ended Synthetic Loss
Mandatory
PM-2 point-to-point
multipoint
n/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 LMM/LMR
Single-Ended Synthetic Loss ITU-T Single-Ended ETH-SLM SLM/SLR
MPLS Japan 2013
G.8013/Y.1731 – PM update
SLM (Synthetic Loss measurement)
Sequence counter (の演算)によるLoss measurement
DMMv1 (Proactive 対応)
15
1 2 3 4
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 MEL Version (0) OpCode (SLM = 55) Flags (0) TLV Offset
5 Source MEP ID Reserved for Responder MEP ID (0)
9 Test ID
13 TxFCf
17 Reserved for SLR: TxFCb (0)
21 [Optional TLVs start here, otherwise End TLV]
25
:
last End TLV (0)
Source MEP ID
& responder ID(p2mpの対応でSLM
にだけ定義)
identifying an unique
test among MEPs(ID識別でon-demand/
proactiveをも識別)
Data TLV 定義(フレーム長定義)
1 2 3 4
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 MEL Version (1) OpCode (DMM=47) Flags TLV Offset (32)5
TxTimeStampf9
13 Reserved for DMM receiving equipment (0)
(for RxTimeStampf)17
21 Reserved for DMR (0)
(for TxTimeStampb)25
29Reserved for DMR receiving equipment (0)
33
37 [optional TLV starts here; otherwise End TLV]41
45
:
last End TLV (0)
On demand
識別 flag 定義
Test ID TLV
Data TLV 定義(後者はフレーム長定義するケースに備えたもの)
MPLS Japan 2013
On-demand/Proactive
識別 flag
G.8013/Y.1731 – PM update
LMMv1 (Proactive 対応)
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
1 2 3 4
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
1 MEL Version (1) OpCode (LMM=43) Flags TLV Offset (12)
5 TxFCf
9 Reserved for RxFCf in LMR
13 Reserved for TxFCb in LMR
17 End TLV (0)
On-demand/Proactive
識別 flag
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 に規定
拡張例: 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)
17
server
EMS
NE
LCT
G.8052
interfaceserver
GUI
client
NMS
interface
GUI
client
MPLS Japan 2013
G.8052 - OAM アーキのモデル(UML)化
OAM Architecture (ME階層込)
MPLS Japan 2013 18
ETH TTP
ETH TTP
ETH CTP(s)
NCMMEP
ETH/ETH
ETH
sublayerboundary
ETH/ETH-m
ETH
ETHD/ETH
ETHDe
ETHD/ETH
ETHDe
ETHG/ETH
ETHG
TCMMEP6x
ETH CTP(s)
NCMMEP
ETHD/ETH
ETHDe
Client Layer CTP
NCMMEP
ETH TTP
CTP Pool
ETH/ETH
ETH
ETH/ETH-m
ETHD/ETH
ETHDe
ETHD/ETH
ETHDe
ETHG/ETH
ETHG
TCMMEP
TCMMEP
6x
CTP Pool
ETH/Client
ETH
ETHD/ETH
ETHDe
ETH
ETHD/ETH
ETHDe
ETH/ETH
ETH
ETHD/ETH
ETHDe
TCMMEP6x
<SRV>/ETH
<SRV>
ETH CTP(s)
Server Layer TTP
ETHxSublayer
ETHxSublayer
ETHxSublayer
sublayerboundary
sublayerboundary
sublayerboundary
Pointer association (user frame flow)
Containment of auxiliary objects for OAM
Containment (user frame flow)
ETHD/ETH
ETHDi
MIP
ETHD/ETH
ETHDi
TCS
ETHD/ETH
ETHDi
MIP
ETHD/ETH
ETHDi
TCS
TCS
TCMGroupMEP
ETHD/ETH
ETHDi
GroupMIP
ETHD/ETH
ETHDi
CTP Pool
ETHD/ETH
ETHDi
GroupMIP
ETHD/ETH
ETHDi
CTP Pool
ETHD/ETH
ETHDi
MIP
ETHD/ETH
ETHDi onlytaggedlayers
onlytaggedlayers
onlytaggedlayers
CC
CC
CC
at mostone
at mostone
at mostone
G.8021 モデル(Connection,
Flow Termination, Adaptation)を
G.8052 Object class に変換 Trail Termination
Point (TTP)
Connection
Termination
Point (CTP)
Cross Connection
(CC))
+ MEP & MIP
+ TCS(Traffic conditioning)
お断り: 図内の字が細かく見づらいと
思いますが詳細は勧告をご参照下さい
G.8052 - OAM アーキのモデル(UML)化
MEP on-demand Diagnostic Functionの例
19
maintenanceEntityGroupEndPointBidirectional
establishOnDemand2-WayMeasurementJob()
OnDemand2-WayMeasurementJobControlcreates
atomic functions
at start time -> Start ()
getIntermediateReport()
Intermediate Report Return
Intermediate request ()
Result ()
at stop time -> Terminate ()
EMS
Result ()PM Report Notification
Object Creation Notification
Object Deletion Notification
object created
object deleted
abortOnDemandMeasurementJob()
deletes
Object Deletion Notification
object deleted
or
Terminate ()
Measu
rem
en
t In
terv
al
Measurement and
Maintenance
MI list (G.8021)
Sequence List Data Dictionary
On-demand
Measurement
Job control
2way 1way Sk
1way So
MEP Control
MEP Source MEP Sink
TTP So TTP Sk
TTP
CTP
CTP So CTP Sk Measurement
JobControl
ETHx/
ETH
ETHx
ETHD/
ETH
ETHD
MEP
Proactive
On-demand
MI_XXX
MI_YYY
… Object Class Diagram
(On-demand Measurement)
EMS MEP(Bidir) On-demand
2way
Atomic Function
(i.e NE)
MEP(Bidir)
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 にも着手
細々ですが、標準化に向けた検討はまだまだ進んでいますし、まだまだ、考えるべきことあります！
MPLS Japan 2013 20
ありがとうございました
