MPLS Japan的ネットワークスライス動向
2021/11/01
栃尾 祐治 (富士通(株))報告内容• ネットワークスライングに関する動向として、IETFでの動向を中心に紹介(お断り) 参照しているInternet draftなど、2021/10時点の動向です。

• 具体的には、IETF TEAS WGで中心に議論を進めている IETF Network Sliceの動向を紹介しつつ、どうNetwork Slicingを実現しようとしているのか紹介• 加えて、 IETF Network Slice の議論が深まり、(IPv6だけでなく) MPLSへの応用検討が進むにつれ、MPLSラベルスタックに対し、(互換性を維持しつつ) 新たなラベルスタックを議論する動きが加速• 本報告ではこのMPLSの件についてもこれまでの経緯と今議論されている状況を紹介 (し、タイトル回収☺)• 参考までに、これら内容はすでにISOC-JP IETF(109, 110)報告会でも報告したもので、今回はこのアップデートに該当• なお、本資料は、本間俊介さん・宮坂拓也さんにもご協力いただきました(感謝)MPLS Japan 2021 (2021/11/1)

2

IETFにおけるNetwork Slicing関連

MPLS Japan 2021 (2021/11/1)

3

Network SlicingにおけるIETFの取り組み• IETF99(2017夏)ごろから、各WG or BoFで検討開始。例えば• Side meeting (IETF98) > pdf• NetSlicing BoF (IETF99) > pdf• COMS BoF (IETF101) > pdf• RTGWG, OPSAWGなど (IETF104) > pdf• TEAS (IETF105) > pdf• IETF105 にて、TEASでNetwork Slicingを検討することが同意され、DT (Design Team) を結成。> pdf (@IETF106)• 参考: TEAS (Traffic Engineering Architecture and Signaling) WG とは• IP, MPLS and GMPLSにおけるTraffic Engineering (TE) に関わる一般的アーキテクチャ、
RSVP-TEなどのシグナリングプロトコルなどを扱う、平たくいうとTE全般に関わることを扱うWG• RFC8453 こと Abstraction and Control of Traffic Engineered Networks (ACTN)もこのWGで進めてきた。他、TE YANG, TE Topology YANGも扱い、現在はRFC3272bisもすすめている
MPLS Japan 2021 (2021/11/1)

4

TEAS WGでのこれまでの取り組み• 主なアウトプット文書 (2021/10現在)(1)全体に関するドラフト (Framework, E2E Slice定義)
概要

ドキュメントhttps://datatracker.ietf.org/doc/html/draft-ietf-teas-ietfnetwork-slices

IETFにおけるネットワークスライス(IETF Network Slice)を定義。
以前は、Definition draftとFramework draftが存在したがこの春にマージ。Network Slice関連で数少ないWG I-Dの一つ。後述

IETF Network Slice use cases
https://datatracker.ietf.org/doc/html/draft-cheng-teasnetwork-slice-usecase

タイトルの通りUse caseを紹介。cloud-network serviceや1IPオペレータ内での複数companyネットワーク運用などの例を紹介

5G End-to-end Network Slice Mapping from the view ofTransport Network (Expired)

5G End-to-end ネットワークを Transport Network (TN)slice (i.e. IETF Network Slice)にどうマッピングするか検討し示した文書。Management / Data plane でのGap分析もあり

Framework for IETF Network Slices

https://datatracker.ietf.org/doc/html/draft-geng-teas-network-slicemapping

IETF Network Slice for 5G and its characteristics(Expired)https://datatracker.ietf.org/doc/html/draft-rokui-5g-ietf-network-slice

5G IETF Network Slicesを定義し、5G End-to-end sliceとIETF
Network Slice Controllerとの関係並びにNBIデータモデル(YANG)を提案するドラフト。後述するが、IETF Network Sliceのベースになっている

MPLS Japan 2021 (2021/11/1)

5

TEAS WGでのこれまでの取り組み• 主なアウトプット文書 (2021/10現在)(2a) ソリューションに関わるドラフト
ドキュメント概要

A Framework for Enhanced Virtual Private
Network (VPN+) Services
https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn

Scalability Considerations for Enhanced VPN(VPN+)
https://datatracker.ietf.org/doc/html/draft-dong-teas-enhanced-vpn-vtnscalability

Applicability of Abstraction and Control of Traffic
Engineered Networks (ACTN) to Network Slicing
https://datatracker.ietf.org/doc/html/draft-ietf-teas-applicability-actnslicing

VPN+として、Network Sliceを提供するVPNとして比較
的長期に亘り議論されたドラフトで、VTN (Virtual
Transport Network) をUnderlayにVPN serviceを提供するための枠組み。Routing拡張やスケールに関する考察など関連ドラフトあり 後述

RFC8453 (ACTN Framework)、特にACTN Virtual
Network (VN)並びにACTN management
Components (i.e., CNC, MDSC, PNC)をベースにNetwork Slicingをどう適用できるかまとめたWG I-DMPLS Japan 2021 (2021/11/1)

6

TEAS WGでのこれまでの取り組み• 主なアウトプット文書 (2021/10現在)(2b) ソリューションに関わるドラフト
ドキュメント

概要

Building blocks for Network Slice Realization in
Segment Routing Network

SR(SR-MPLS, SRv6)によりNetwork Sliceをどう実現するかを記したドラフト。TEAS/SPRINGの双方のWGで展開 後述

https://datatracker.ietf.org/doc/html/draft-ali-teas-spring-ns-buildingblocks

Realizing Network Slices in IP/MPLS Networks
https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet

Packet Network Slicing using Segment Routing(Expired)https://datatracker.ietf.org/doc/html/draft-peng-teas-network-slicing

IP/MPLSネットワーク上でネットワークスライスを実現する提案。後述5Gサービス向けにTransport network (TN)をどうス
ライス実現するか手法を示したもので、SR policyを拡張したAII-based mechanismを紹介

MPLS Japan 2021 (2021/11/1)

7

TEAS WGでのこれまでの取り組み• 主なアウトプット文書 (2021/10現在)(3) IETF Network Slice Controller のNBIに関するドラフト
ドキュメント概要

IETF Network Slice Controller and its associateddata models (Expired)

IETF Network SliceにおけるControllerの内部構造ならびに、そこで用いられる各種data modelに関する考察的なInformational draft

https://datatracker.ietf.org/doc/html/draft-contreras-teas-slicecontroller-models

IETF Network Slice Service YANG Model
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbiyang/

IETF Network Slice use cases and attributes forNorthbound Interface of controllers
https://datatracker.ietf.org/doc/html/draft-contreras-teas-slice-nbi

IETF Network Slice Service YANGを定義。IETF
Network Slice Customer - IETF Network SliceController (NSC)間、すなわち NSC NBIを対象にする。
WG I-DIETF Network Sliceを利用するユースケースを整理し、そのユースケースを満たすためにNBIに埋め込むべき情報を整理するドラフト

MPLS Japan 2021 (2021/11/1)

8

TEAS WGでのこれまでの取り組み• 主なアウトプット文書 (2021/10現在)(3) IETF Network Slice Controller の SBI に関するドラフト
ドキュメント概要

YANG Model for Scalable VTN

VPN+におけるYANG定義

https://datatracker.ietf.org/doc/html/draft-geng-teas-enhanced-vpnscalable-vtn-yang

A VTN Network YANG Module
https://datatracker.ietf.org/doc/html/draft-wd-teas-vtn-network-yang

Instantiation of IETF Network Slices in service
providers networks
https://datatracker.ietf.org/doc/html/draft-barguil-teas-network-slicesinstantation

IETF Network Slice YANG Data Model
https://datatracker.ietf.org/doc/html/draft-liu-teas-transport-networkslice-yang

YANG Data Model for Slice Policy
https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-slice-policy

IETF Network Slice Controller – Network Controller (i.e,
NSC SBI)の動作定義。NBIからのSliceリクエスト (例えば
LxVPN service) をもとにLxVPN (LxVPN network) 設定するための手順を定義IETF Network Slice全体のYANG data modelを提案。Network
Topology YANG (RFC8345), TE Topology YANG (RFC8765)
をベースにNetwork Sliceを定義
IP/MPLS networksにおけるSlice Policyに対するYANGを定義するドラフト。draft-bestbar-teas-ns-packet に関連

MPLS Japan 2021 (2021/11/1)

9

IETFが (３GPP) 5G slicingで目指すところ(またはIETF Network Slice定義の契機)• TS28.530でいうところのTransport Network (TN) 念頭に、 Network Slicingはじめ、UP,
Controller などのManagement planeを定義• 初期の Framework draft はTransport network slice定義し、これがIETF Network Sliceの大元になっている （大元であり IETF Network Slice が TN を対象にしているとは明言していない）
draft-clt-dmm-tn-aware-mobility から。このドラフトでは、表向きTS28.530は参照していないが、明らかに意識
5G Control and Management Planes+------------------------------------------------------------------------+| +--------------------------------------------------------------------+ |
| |
(TNF)
5G Management Plane
(TNF)
| |
| +----+-----------------+-------------+---------------+-----------+---+ |
|
|
|
|
|
|
|
| +----+-----+|
F1-C +----+-----+|
N2 +----+---+ || ||----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | || |||+----+-----+|+----+---+ |+-||-----------|-------------|---------------|-----------|-----+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ACTN|| ACTN|||+---+---+|+---+---+
|
|
|
|
|
|
|
|
|
| gNB-DU|| SDN-C |E1| SDN-C |
|
|
|
|
|
|
|
|
|
|
|
+---+---+|+---+---+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
__ +__|___+__
|
|
|
__/
¥__
+--+---+
__/
¥__
+-+-+
|
|
/
IP
¥
| gNB |/
IP¥||
UE--*||-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN+----------+¥____/+------+
¥__
__/
+---+
¥______/¥______/|------ F1-U -------||------ N3 OR N9 ------|* Radio and Fronthaul

Figure 1: Backhaul and Mid-haul Transport Network for 5G

MPLS Japan 2021 (2021/11/1)

https://www.isoc.jp/wiki.cgi?action=A
TTACH&page=IETF105Update&file=ietf105%2Dmiyasaka%2Epdf

10

Framework for IETF Network Slices
draft-ietf-teas-ietf-network-slices• 以下、Frameworkドラフトと略記• ドラフトの構成(目次抜粋)• 原則05版(2021/10)に沿って紹介• FYI: 以前はDefinitionとFrameworkドラフ
トが存在。2021/4にマージ• draft-ietf-teas-ietf-network-slice-definition• draft-ietf-teas-ietf-network-slice-framework

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .
1.1. Background . . . . . . . . . . . . . . . . . . . . . . .
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . .
2.1. Core Terminology . . . . . . . . . . . . . . . . . . . .
3. IETF Network Slice Objectives . . . . . . . . . . . . . . . .
3.1. Definition and Scope of IETF Network Slice . . . . . . .
3.2. IETF Network Slice Service . . . . . . . . . . . . . . .
3.2.1. Ancillary CEs . . . . . . . . . . . . . . . . . . . .
4. IETF Network Slice System Characteristics . . . . . . . . . .
4.1. Objectives for IETF Network Slices . . . . . . . . . . .
4.1.1. Service Level Objectives . . . . . . . . . . . . . .
4.1.2. Service Level Expectations . . . . . . . . . . . . .
4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . .
4.3. IETF Network Slice Decomposition . . . . . . . . . . . .
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1. IETF Network Slice Stakeholders . . . . . . . . . . . . .
5.2. Expressing Connectivity Intents . . . . . . . . . . . . .
5.3. IETF Network Slice Controller (NSC) . . . . . . . . . . .
5.3.1. IETF Network Slice Controller Interfaces . . . . . .
5.3.2. Management Architecture . . . . . . . . . . . . . . .
5.4. IETF Network Slice Structure . . . . . . . . . . . . . .
6. Realizing IETF Network Slices . . . . . . . . . . . . . . . .
6.1. Architecture to Realize IETF Network Slices . . . . . . .
6.2. Procedures to Realize IETF Network Slices . . . . . . . .
6.3. Applicability of ACTN to IETF Network Slices . . . . . .
6.4. Applicability of Enhanced VPNs to IETF Network Slices . .
6.5. Network Slicing and Slice Aggregation in IP/MPLS Networks
7. Isolation in IETF Network Slices . . . . . . . . . . . . . .
7.1. Isolation as a Service Requirement . . . . . . . . . . .
7.2. Isolation in IETF Network Slice Realization . . . . . . .
8. Management Considerations . . . . . . . . . . . . . . . . . .
9. Security Considerations . . . . . . . . . . . . . . . . . . .
10. Privacy Considerations . . . . . . . . . . . . . . . . . . .

MPLS Japan 2021 (2021/11/1)

3
4
5
5
7
7
8
10
10
10
11
13
15
18
18
19
19
21
23
24
25
27
27
29
30
31
31
32
32
32
32
32
34

11

Frameworkドラフト

3.1 Definition of IETF Network SliceAn IETF Network Slice Service enables connectivity between a set of
CEs with specific Service Level Objectives (SLOs) and Service Level
Expectations (SLEs) over a common underlay network.

• draft-ietf-teas-ietf-network-slices-04
section-3.1 から

An IETF Network Slice combines the connectivity resource requirements
and associated network behaviors such as bandwidth, latency, jitter,and network functions with other resource behaviors such as computeand storage availability. The definition of an IETF Network Slice
Service is independent of the connectivity and technologies used in
the underlay network. This allows an IETF Network Slice Service
customer to describe their network connectivity and relevant
objectives in a common format, independent of the underlying
technologies used.

• IETF Network Slice (の定義) とは…
• logical network topology• connectivity resource requirements &associated network behaviors• Underlayから独立•

これにより IETF Network Slice Service
Customerが、connectivityなどを提供可能

IETF Network Slices may be combined hierarchically, so that a network
slice may itself be sliced. They may also be combined sequentiallyso that various different networks can each be sliced and the network
slices placed into a sequence to provide an end-to-end service. This
form of sequential combination is utilized in some services such as
in 3GPP's 5G network [TS23501].

• 階層的に提供可 & 横方向に結合可• technology-agnostic• なお ”Slice” については、ある user traffic を他のものから分離するための特性および動作と定義しているが、IETF Network Slice は、(大雑把に記すと) Underlay network がネットワーク装置の変更に対応でき、かつSLO/SLE(Service levelobjective/Expectation)を満足できるものを想定している

An IETF Network Slice Service is technology-agnostic, and its
realization may be selected based upon multiple considerations
including its service requirements and the capabilities of theunderlay network.
The term "Slice" refers to a set of characteristics and behaviours
that separate one type of user-traffic from another. An IETF Network
Slice assumes that an underlay network is capable of changing theconfigurations of the network devices on demand, through in-band
signaling or via controller(s) and fulfilling all or some of SLOs/
SLEs to all of the traffic in the slice or to specific flows.

MPLS Japan 2021 (2021/11/1)

12

Frameworkドラフト

3.2 IETF Network Slice Service• 04版で3.2章として追加• IETF network slice serviceを提供すると言うことは：CE (customer’s endpoints) 起点で定義し、CE間を connectivity
matrices (p2p, p2mp等)で定義の上、CE間にSLO/SLEを提供すると言うこと• SLO: Service Level Objective (SLO)• SLE：Service Level Expectation (SLE)• Connectivity matrix ないしは Slice connection types (04版 4.2.1章) との関係を05版で大幅更新。3.2章でConnectivity matrix を明確化し、 Sliceconnection types は05版で削除

MPLS Japan 2021 (2021/11/1)

13

Frameworkドラフト

4. IETF Network Slice System Characteristics
4.1. Objectives for IETF Network Slices

4.2. IETF Network Slice Endpoints (NSE)• Service level Characteristics• 主な定義••••• conceptual points of connection to
IETF network slice.
• identified by a unique ID in the context
of an IETF Network Slice customer

Service Level Indicator (SLI)
Service Level Objective (SLO)
Service Level Expectation (SLE)Service Level Agreement (SLA)• このうち、Measurable なものとしてEndpointに提供できる SLO (例えば、latency, BW など)と、SLE について紹介。

• 04版までではEndpointの解釈(vs CE, PE)をめぐり議論継続中、05版で明確化し更新• SLE の例は以下の通り
•
•
•
•
•

Security
Geographic Restrictions
Maximal Occupancy Level
Isolation
Diversity

MPLS Japan 2021 (2021/11/1)

14

Frameworkドラフト

5. Framework• 5.1 IETF Network Slice Stakeholders• Orchestrator• IETF Network Slice Controller (NSC)• Network Controller• 5.3: Interface of IETF Network Slice Controller+------------------------------------------+| Consumer higher level operation system||(e.g E2E network slice orchestrator)|+------------------------------------------+A| NSC NBI
V+------------------------------------------+|IETF Network Slice Controller (NSC)|+------------------------------------------+A| NSC SBI
V+------------------------------------------+|
Network Controllers|+------------------------------------------+• 5.4: IETF Network Slice Structure|------------------------------------------|
NSE1 O....||....O NSE2
.
|
|
.
.
|
IETF Network Slice|.
.
| (SLOs e.g. B/W > x bps, Delay < y ms) |.
NSEm O....||....O NSEn|------------------------------------------|== == == == == == == == == == == == == == == == == == == == == ==
.--.
.--.
[EP1]
(
)- .
(
)- .
.
.' IETF' SLO .' IETF'.
( Network-1 ) ... ( Network-p )`-----------'`-----------'
[EPm]

[EP2]
.
.
[EPn]

Legend
NSE: IETF Network Slice Endpoints
EP: Serivce/tunnel/path Endpoints used to realize the
IETF Network Slice

MPLS Japan 2021 (2021/11/1)

15

Frameworkドラフト

Realizing IETF Network Slices / Isolation
6. Realizing IETF Network Slices

7. Isolation in IETF Network Slices• アーキテクチャは次ページ• Requirement (いずれもmay)• 実現手法 (Controller(NSC)とcustomerの関係に着目)• The NSC exposes the network slicing capabilities that
it offers for the network it manages.
• The customer may issue a request to determine
whether a specific IETF Network Slice could be
supported by the network. <..>• The customer requests an IETF Network Slice. The
NSC may respond that the slice has or has not beencreated, <..>• When processing a customer request for an IETF
Network Slice, the NSC maps the request to the
network capabilities and applies provider policies
before creating or supplementing the resource partition.

• 他の slice customer の影響を受けないよう
IETF network slice deliveryを要求していい• Providerの変更や他のslice customerの動作状況に対して、影響を受けない度合いを定義していい• このことを SLE (4.1.2) として表現していい• Isolation は、 underlying network において行われ、dedicatedからsharingまで様々な
resource partitioning によって提供される• 代表例は、VPN (L3VPN, L2VPN, EVPN)• Applicability• ACTN• VPN+• IP/MPLS Networks
MPLS Japan 2021 (2021/11/1)

16

Frameworkドラフト

Frameworkドラフト近況• 6.1 Architecture of an IETF Network Slicehttps://datatracker.ietf.org/meeting/interim-2021-teas01/materials/slides-interim-2021-teas-01-sessa-open-issuesframework-for-ietf-network-slices-00

MPLS Japan 2021 (2021/11/1)

17

IETF Network Slice実現例

MPLS Japan 2021 (2021/11/1)

18

A Framework for Enhanced Virtual Private Network (VPN+) Services
draft-ietf-teas-enhanced-vpn• Network Sliceを提供するVPNとして比較的長期に亘り議論されたドラフト
Enhancement
Resource
Awareness• VTN SR
(Virtual
Transportwith
Network)をUnderlayにVPN •serviceを提供するための枠組みであり、ドラフ
Based on forwarding plane resource partitioning
トのメインはこのVTNに関わるもの• E.g. allocate dedicated link resources for different virtual
networks• VTNの提供手段(の一つ)にSRを想定• Different SIDs are used to identify different set of network
N ode-SID

Adj- SID

N ode-SIDA• SR詳細は、SRPRING
WG他にドラフトあり
resources• draft-ietf-spring-sr-for-enhanced-vpn• Multiple adj-SIDs for one link
• Multiple prefix-SIDs for one node
• draft-dong-lsr-sr-enhanced-vpn-06

B

Adj- SID

Resource
Partition

Adj- SIDC• SR virtual networks are built with different set of SIDs

• TEAS WGでは、このドラフトの課題で• Traffic in different virtual networks are steered to isolatedresources according to the SIDs usedある拡張性を考察したドラフトも議論• VPNs can map to dedicated or shared virtual networks• draft-dong-teas-enhanced-vpn-vtn-scalability

10 1002

1 03

1
1001

2 012002

203

301 3002

303

2001

3001
1003

102
Slice 1

2003

202
Slice 2

302
Slice 3https://datatracker.ietf.org/meeting/103/materials/slides-103spring-segment-routing-for-enhanced-vpn-service-00.pdf
https://datatracker.ietf.org/meeting/110/materials/slides-110teas-scalability-considerations-for-enhanced-vpn-vpn-00

MPLS Japan 2021 (2021/11/1)

19

Realizing Network Slices in IP/MPLS Networks
draft-bestbar-teas-ns-packet(-04)
IP/MPLSネットワーク上でネット
ワークスライスを実現する提案⚫ Diffservをベースとした提案⚫ PEルーターにおいて、CEから受信したIPパケットに、スライスの識別子を示すMPLSラベル(右図ではSlice
Selector/Label)と、経由すべき各ルーターのMPLSラベルを付与して転送⚫

同一スライス
内のQoS➢ H-QoSとスライシング➢ 同一ネットワークスライス内でのQoSを実現➢ 途中のPルーターは、Slice label毎のQueueを作成、その下で実際のDSCPの値(もしくはMPLS Label TCbit)に従ったQueueを割り当て異なるスライス間のQoS
https://datatracker.ietf.org/meeting/109/materials/slides-109-teasrealizing-network-slices-in-ipmpls-networks-01

MPLS Japan 2021 (2021/11/1)

20

Realizing Network Slices in IP/MPLS Networks (続)draft-bestbar-teas-ns-packet⚫

Label はSlice Policy Data Plane
Selector を示すものとして定義されSlice aggregateをに属する⚫ Slice aggregate: Slice 定義 (policy)に属しまた packet forwarding を兼え、
IETF network slice traffic streamを定義するもの⚫

Slice Policy Data Plane Selector
は、MPLSでは以下のドラフトにより定義されるとある•draft-decraene-mpls-slid-encodedentropy-label-id••

同一スライス
内のQoS

詳細は次スライド

draft-kompella-mpls-mspl4fa•

異なるスライス間のQoS

詳細は後述(MPLSパート)
https://datatracker.ietf.org/meeting/109/materials/slides-109-teasrealizing-network-slices-in-ipmpls-networks-01

MPLS Japan 2021 (2021/11/1)

21

Building blocks for Network Slice Realization in Segment Routing
Networkdraft-ali-teas-spring-ns-building-blocks• SR(SR-MPLS, SRv6)によりNetwork Slice
をどう実現するかを記したドラフト• TEAS/SPRINGの双方のWGで展開• 以下の構成要素

SLID Attributes• SLIDはIPv6, MPLSで別ドラフトにて定義• MPLSでは、Entropy labelと同じ使い方(Label一部にSLID定義)で提供を提言

SLID for MPLS

• draft-decraene-mpls-slid-encoded-entropy-label-id• Reference• SLIDFlexible
enablesthedifferentiate treatment• SR Policy with or without
Algorithm.
H-Queue (Slid 1)– QoS/ DiffServ –policyon a per SLID
draft-decraene-mpls-slid-encoded-entropy-label-id• TI-LFA with O(50 msec) protection in the slice• SLID construct is like QoS• Similar to draft-filsfils-spring-srv6-stateless-slice-id
for
60% BW
underlay.
– Independent of Routing and Topology
MPLS networks• SR VPN• Stateless• Ingress PE• SR Service Programming
(NFV,
SFC).
• Backward
compatible–
MAY classify the traffic to a slice and 40%
setsBW
the following in– Incremental deployments• OAM and Performance
Management(PM).
the entropy label of MPLS label stack:Seamless
Building
BlocksExample H-Queues (Slid 2)> SLID in the x MSB of the entropy label• QoS using DiffServ
1 bit of TTL field (ELC)> SPI bit (SLID Presence Indicator) in SLID
the one• Stateless
Networkand
Slice
Identification (SLID)
1• Flex-Algo
TI-LFA2
Alg128• Per
Slice
Differential Treatment
4
30– The backup
is optimizedperFlex-Algo• Orchestration
at thepath
Controller

MPLS label stack

EXP0

EXP1

Entropy Label Indicator

EXP2

EXP3

Entropy LabelEXP0Payload

EXP1

EXP2

EXP3

•

– The SLID is used to apply per-slice
policies
65• Flex-Algo, TI-LFA and SLID
本ドラフトでは、先のns-packet
draftで定義• Backward Compatible– Slid does not create a new instance of Flex-Algo

Entropy Label
Entropy

EXP S

TTL

EXP S

ELC

9

Alg1298

7SLID

EntropyのSLIDに基づくQoS処理を実行したり、– Node not supporting SLID provides slicing using non-SLID
x bits20-x bits
8 bitsUnderlay building blocks shared>Scalablebuilding blocks (default SLID)
among SLIDs
Flex-algoによるSlice提供に貢献することが– TI-LFA works seamlessly for each SLID
https://datatracker.ietf.org/meeting/111/materials/slides-111-teas-09-buildingblocks-for-network-slice-realization-in-segment-routing-network-00.pdf
記されている>The slid is stateless
SLID 2>Backup paths provide differentiated treatment
MPLS Japan 2021 (2021/11/1)

22

ここから話はMPLSに
MPLS Japanらしくなりました ☺

MPLS Japan 2021 (2021/11/1)

23

ここからお話しすること• IETF110の PALS/MPLS/DetNet/SPRING ジョイントセッションで、ここ最近で急増した新たなMPLSラベルスタックに対するドラフトを集中して議論• 具体的には、 MPLSラベルスタックの底 (BoS: Bottom of Stack) の上も下も拡張バリエー
ションが増えたため、是非を確認する議論を開催• 特ににdraft-kompella-mpls-mspl4faが特にインパクト大• IETF110の後もOpen MPLS DT meeting を開催• この資料では、MPLSラベルスタックに関わる経緯を過去に遡り紹介• FYI: MPLS Label Stack →(Figure 1/RFC3032)• EXPはRFC5426でTCに(Traffic Class)012
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label|
Label| Exp |S|
TTL
| Stack+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label:
Exp:
S:
TTL:

Label Value, 20 bits
Experimental Use, 3 bits
Bottom of Stack, 1 bit
Time to Live, 8 bits

MPLS Japan 2021 (2021/11/1)

24

歴史を振り返る

MPLS Japan 2021 (2021/11/1)

25

Keywords• PW Control Word(RFC4385), ACH (RFC5085), そして G-ACh(RFC5586)• そして実際 PW Control Word や G-ACh使っているRFCなど• 例えば、RFC4448 (Ethernet PW), RFC6347 (MPLS Loss/Delay測定)• そして忘れちゃいけない、ITU-T G.8113.1 (& RFC6671)• Special-Purpose label (was Reserved label)• RFC3032• RFC7274• RFC9017• 代表例としてRFC8595• 参考• https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml

MPLS Japan 2021 (2021/11/1)

26

その昔の話• MPLS/PWや、MPLS-TPが活気づいていたころの話(2005年ごろ)• PWE3 (Psuedowire (PW) Emulation Edge to Edge) WGでのお話• このWGはConcluded し、現在は PALS WG に

• PWとは: 主にMPLSを使って回線技術(Ethernet, TDM)を提供するための技術を定義• RFC3985 に基づくアーキモデルと、RFC4385 (PW control word)含めた Formatを構成• PE間で定義されるPWラベル(BoS)に PW Control word が定義される(こともある)• PW control wordの用途: FragmentationやSequence numberの定義など
PSN(Packet Switched Network)

PW Label (BoS) Label20bit + TC 3bit
+ BoS 1bit + TTL 8bit

PW control Word

 0000 + PW encap依存(28bit)

PSN Tunnel label
PW1

CE1

Attachment
CircuitPE1

PW2

PSN Tunnel
PE1

Attachment
Circuit

CE2

PayloadPseudowire (PW)
Emulated Service

MPLS Japan 2021 (2021/11/1)

27

PWでもOAMが必要だよね…ということで• RFC5085 “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires”• VCCV control channel messagesを定義• HeaderはPW Associated Channel Header。First Nibble = 0001で in-band VCCVを宣言|<-------------- Emulated Service ---------------->|||<---------- VCCV ---------->||||<------- Pseudowire ------->|
|
|
|
|
|
|
|
|<-- PSN Tunnel -->|
|
|
|
V
V
V
V
|
V
AC
+----++----+
AC
V+-----+|| PE1|==================| PE2||+-----+||----------|............PW1.............|----------||| CE1 |||||||
| CE2 |||----------|............PW2.............|----------||+-----+ ^ |||==================||| ^ +-----+^ |+----++----+| | ^| |Provider Edge 1
Provider Edge 2 | || || |Customer || Customer
Edge 1|| Edge 2||||
Native service
Native service
MPLS Japan 2021 (2021/11/1)

0001

VersionLSP Label

TC, S, TTLPW LABEL

TC, S(=1), TTL

Reserved

Channel typeACh message(LSP pingなど)

28

MPLS-TPが出てきてOAMは…
• OAM は、GAL + G-ACh (RFC5586) で定義• G-ACh: PW Associated Channel (RFC4385, Clause 5.1) を一般化した Associated Channel を定義• G-ACh が伴っている LSP に対して GAL = 13 (BoS) を付加• 新規 Reserve = 13 を使用• PW VCCV の場合は、GAL は不要になる。またG-ACh header とは呼ばず(前のスライド参照)

G-Ach
Header0001

VersionLSP Label

TC, S, TTL

GAL (L=13)

TC, S(=1), TTL

Reserved

Channel type

ACH TLV (header 含む)
draft-ietf-mpls-tp-ach-tlv[optional]
G-ACh message• 参考までに、GAL + G-ACh を用いている文書: RFC6374; 6426; 6427; 6428; 6435; 8169(; ITU-T G.8113.1)
MPLS Japan 2021 (2021/11/1)

29

Special Purpose Labels (SPL) & Extended SPL (eSPL)• RFC7274 & RFC9017• Label 0-15(SPL (ex Reserved label) or bSPL) と 16-255(eSPL)の使用について• https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml
Value0

Description

Reference

IPv4 Explicit NULL Label[RFC3032]

1

Router Alert Label[RFC3032]

2

IPv6 Explicit NULL Label[RFC3032]

3

Implicit NULL Label[RFC3032]

4-6

Unassigned

7

Entropy Label Indicator(ELI)[RFC6790]

8-12Unassigned

13

Generic AssociatedChannel Label[RFC5586]

14

OAM Alert Label[RFC3429]

15

Extension Label (XL)

[RFC7274][RFC90
17]

Value

Description

Reference

0-15

Reserved. Never to be madeavailable for allocation.

[RFC7274]

16

Metadata Label Indicator (MLI)[RFC8595]

17

Metadata Present Indicator(MPI)[RFC8595]

18-239Unassigned

240-255

Reserved for Experimental Use[RFC7274]

256-1048575

Reserved. Not to be madeavailable for allocation without a
new Standards Track RFC todefine an allocation policy.

[RFC7274]

MPLS Japan 2021 (2021/11/1)

30

RFC6790 (& RFC6391)• RFC6790• The Use of Entropy Labels in MPLS Forwarding• Entropy Label Indicator (（ELI = 7) を使用。
Entropy MPLS labelと合わせ、ECMPを提供 (TTL=0)• 以下の図は、PW前提に描かれているがPW必須ではなくEntropy MPLS Label が BoSになることもある• 参考までに、EMCP目的であれば、FAT label(Flow label)という解もあるにはある• RFC6391• Flow-Aware Transport of Pseudowires over an
MPLS Packet Switched Network• PW 前提 (必須)に、FAT label (BoS) を定義。TTL=1

https://packetpushers.net/fat-or-entropy-label/
MPLS Japan 2021 (2021/11/1)

31

RFC8595• An MPLS-Based Forwarding Plane for Service Function Chaining (SFC)• Metadata 定義に eSPL である MLI (Metadata Label Indicator), MPI (Metadata Present
Indicator) を定義 (Metadata LabelがBoSになる)----------------~ Tunnel Labels ~+----------------+~
Optional~~ Entropy Label ~+----------------+ - - |SPI Label|+----------------+ Basic unit of MPLS label stack for SFC|
SI Label|+----------------+ - - | Extension = 15 |+----------------+|
MLI(16)|+----------------+| Metadata Label |+----------------+
~
Other
~
|
Metadata|~ Label Triples ~+----------------+
Figure 5: The MPLS SFC Label||~
Payload~Stack for Label Swapping with||
Metadata Label （一部加筆）----------------------------------~
Tunnel Labels~+-------------------+~
Optional~~
Entropy Label~+-------------------+ - - | SFC Context Label |+-------------------+ Basic unit of MPLS label stack for SFC|
SF Label|+-------------------+ - - ~~+-------------------+| SFC Context Label |+-------------------+|SF Label|+-------------------+|
Extension = 15 |+-------------------+|
MPI(17)|+-------------------+| Metadata Label|+-------------------+
Figure 8: The MPLS SFC Label||~
Payload~Stack for Label Stacking||
Carrying Metadata （一部加筆）-------------------

MPLS Japan 2021 (2021/11/1)

32

IETF110〜IETF111とMPLS Open DTでの議論

MPLS Japan 2021 (2021/11/1)

33

IETF110&111 PALS/MPLS/DetNet/SPRING agenda*********************************************************************IETF 111 PALS/MPLS/DetNet/SPRING Joint Meeting
Joint session with PALS, MPLS, DetNet
Tuesday, 27 July 2021 - 16:00-18:00 PDT Room: 6120/120 min allocated**********************************************************************
Chairs: Stewart Bryant and Andy Malis
Secretary: David Sinicrope*********************************************************************IETF 110 PALS/MPLS/DetNet/SPRING Joint Meeting
Friday, 12 March 2021 - 12:00-14:00 UTC Room:7
120/120 min allocated**********************************************************************
Chairs: Stewart Bryant and Andy Malis
Secretary: David Sinicrope
1. 5 min - Chairs’ intro - Andy MALIS

5 min - Chairs’ intro - Andy MALIS
20 min - MPLS Open DT summary and status - Stewart BRYANT
In-stack Indicators

2. 20 min - MPLS architectural considerations - Stewart BRYANT
3. 10 min - DetNet data plane, RFCs 8938, 8939, 8964 - Balázs VARGA

10 min - draft-kompella-mpls-mspl4fa FAI MSPL I-D: Kireeti KOMPELLA
10 min - draft-bryant-mpls-aux-data-pointer-00: Stewart BRYANT
5 mins- draft-song-mpls-eh-indicator: Haoyo SONG

4. 10 min - Generic delivery functions - Zhaohui (Jeffrey) ZHANG
https://tools.ietf.org/html/draft-zzhang-intarea-generic-delivery-functions-00

Meta-data Encoding Options:

5. 15 min - MPLS in-situ OAM - Rakesh GANDHI
https://tools.ietf.org/html/draft-gandhi-mpls-ioam-sr-06

20 min - MPLS Extension Header: Enabling Extensible In-Network Services - Haoyu SONG
Objective: Recap the solution proposal with some updates based on the DT meeting discussion.

6. 10 min - Multi-purpose Special Purpose Label for Forwarding Actions - Kireeti KOMPELLA
https://tools.ietf.org/html/draft-kompella-mpls-mspl4fa-00
7. 45 min - Discussion - all

8. 5 min - Chairs’ summary - Stewart BRYANT

https://datatracker.ietf.org/meeting/110/materials/agenda-110-pals

draft-song-mpls-eh-indicator
draft-song-mpls-extension-header
draft-andersson-mpls-eh-architecture
Draft-andersson-mpls-eh-label-stack-operations
10 min - draft-zzhang-intarea-generic-delivery-functions GFD Encodings - Jeffery ZHANG
35 min - Discussion - All
5 min - Chairs’ summary - Stewart BRYANT

https://datatracker.ietf.org/meeting/111/materials/agenda-111-pals
MPLS Japan 2021 (2021/11/1)

34

Multi-purpose Special Purpose Label for Forwarding Actions
draft-kompella-mpls-mspl4fa• IETF110で話題を引き起こした最大※のドラフト (※個人の感想です)• ドラフトの目的は、MPLSパケットに“Forwarding Actions Indicator” (FAI)ならびに“Forwarding Actions
Data” (FAD)を定義し、Slice ID (GISS (Global Identifier for Slice Selector))やNFFRR(No Further Fast
Reroute)などの多目的な動作を、bSPL(base SPL)を使って提供すること• 提案の背景には、MPLS label stack処理(Forwarding Engine)にあり• スタック数に関わりなく Label値と BoSは見るものの、TC (ex EXP) と TTL は初段(Top of Stack)しか扱わない• Top of Slackにない、SPLに対しては、SPLは見るがTCやTTLは処理には関わらない → 拡張できるでは？

https://datatracker.ietf.org/meeting/110/materials/slides-110-pals-6-10-min-multipurpose-special-purpose-label-for-forwarding-actions-kireeti-kompella-00

MPLS Japan 2021 (2021/11/1)

35

Multi-purpose Special Purpose Label for Forwarding Actions
draft-kompella-mpls-mspl4fa-01
012
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
TCS
TTL------------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|(previous forwarding label| TC |0|
TTL|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Forwarding Actions Indicator |H|A|N|S|E G|F|h| edist |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|LS Forwarding Actions Header|S||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|LS Forwarding Actions Data
|S||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
More LS FAD and/or other labels|S||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|End of Stack label|1||+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|b b b b| Payload (potentially, PL FAD)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Payload|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flag Meaning---- ------H FAH (Forwarding Action Header)
E Entropy
G GISS
N NFFRR
F Flow ID
A LS FAD is present not=============h PL FAD contains hop-by-hop information
edist “distance to End of Stack”• Forwarding Actions IndicatorをbSPLとして定義。かつ、TC, TTLにも特別な用途を持たせる• Forwarding Actions Indicator には Entropy, Flow IDのほか、NFFRR(No Further Fast Reroute), GISS (Global
Identifier for Slice Selector)といった要素(Action)も定義し、actionの組み合わせでFADを定義することを示唆
MPLS Japan 2021 (2021/11/1)

36

他のインプットドラフト• draft-song-mpls-extension-header-05• draft-song-mpls-eh-indicator-03• Extension Header (EH)のほか、EH indicator(GAL+G-AchやELIを想定), HEH 定義•

EHには Header Specific Dataも含まれる

031+--------+--------+--------+--------+ ¥|| |~MPLS Label Stack
~ |
|
| |
+--------+--------+--------+--------+ ||EH Indicator (TBD)|> MPLS Label Stack+--------+--------+--------+--------+ | (extended with EHI)|
| |~MPLS Label Stack
~ |
|
| |
+--------+--------+--------+--------+ <| Header of Extension Headers (HEH) | |+--------+--------+--------+--------+ ||| |~Extension Header (EH) 1
~ |
|
| |
+--------+--------+--------+--------+> MPLS EH Fields~~ | (new)+--------+--------+--------+--------+ ||| |~Extension Header (EH) N
~ |
|
| |
+--------+--------+--------+--------+ <|| |~Upper Layer Headers/Payload~> MPLS Payload|| | (as is)+--------+--------+--------+--------+ /• draft-andersson-mpls-eh-architecture-02•

MPLS Extension Header Architecture• draft-andersson-mpls-eh-label-stackoperations-02•

MPLS Label Operations in MPLS EH capable networks• in-network servicesなどの情報を伴う、EHの転送手段について定義。draft-songとも連携はしている。また
GAL+G-ACh でなく eSPLなどのケースも許容

MPLS Japan 2021 (2021/11/1)

031+--------+--------+--------+--------+|
MPLS Label Stack|+--------+--------+--------+--------+|GAL (s-bit = 1)|+--------+--------+--------+--------+|
ACH Type = (EH E2E/HBH/BOTH)|+--------+--------+--------+--------+| Header of Extension Headers (HEH) |+--------+--------+--------+--------+||~
Extension Header (EH) 1~||+--------+--------+--------+--------+||~
Extension Header (EH) N~||+--------+--------+--------+--------+||~
Upper Layer Protocols/Payload~||+--------+--------+--------+--------+* If eSPL then replace GAL with
XL+EHL* If SPL then ACH not required;
HEH follows XL+EHL directly

37他のインプットドラフト• draft-bryant-mpls-aux-data-pointer-00• Top of Stackの配下にポンターを示す
SPLを定義• Pointer SPL は拡張データ (AncillaryData)を参照し処理• Pointer SPL は配下のスタックに含めることも可。次のToSが処理される際に連動して処理•• (参考) draft-zzhang-intarea-genericdelivery-functions-02• Generic Delivery Functions (GDF)• IPv6のFragmentationヘッダをより一般的に定義
して、MPLSなどにも適用可能にしたもの+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header | Hdr Ext Len |Fragment Offset|Res|M|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Identification|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-------------------------+L1 |Top of Stack|• 左のMPLS EH Fieldsに対し適用可能とし、上+-------------------------+
Fragmentationヘッダを拡張しかつ記MPLSに特L2 |Pointer SPL|-----+
化した、Generic Fragmentation Header (GFH)も+-------------------------+
|
わせて定義
|
|
|
.
.
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header | Hdr Ext Len |Fragment Offset|R|S|M|.
.
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+||||
Fragment/Source Identification (variable)|+-------------------------+|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Bottom of Stack||===============================||
Ancillary Data||
• その他、 draft-bryant-mpls-dev-primer (A Primer.
.
|
on the Development of MPLS (Expired)) に幾つかの.
.<----+
事例あり||+-------------------------+
MPLS Japan 2021 (2021/11/1)
38

MPLS Open DTでの議論(進行中)• 目的と課題定義• Directives: https://trac.ietf.org/trac/mpls/wiki/MPLSOpenDT• 課題: draft-andersson-mpls-open-dt-questions• デザインの方向性（議論詳細）：• Use case• In-stack data (ISD)データ構成• SPL または識別子(Indicator)の検討• BoS配下のデータ構成(PSD: Post Stack Data)について• 既存フォーマット(ACH, GAL/GACh, DETNET control-word)との互換性の検討• BoS配下のデータを示す、識別子(Indicator)の検討• 現在のOutput• MPLS Indicators and Ancillary Data (MIAD)の定義に向け:• 要求文書• https://datatracker.ietf.org/doc/html/draft-bocci-mpls-miad-adi-requirements-00• MIADの定義・構成(on-going)• Wiki にて展開中。用語、ISD, PSD構成など
MPLS Japan 2021 (2021/11/1)

39

MPLS Open DTでの議論(進行中)• Use case
• https://trac.ietf.org/trac/mpls/wiki/Usecases• In-situ OAM• Network Slicing• Time Sensitive Networking• NSH Based SFC• Segment Routing with SRH• Network Programming• Application Aware Networking (APN)•…

MPLS Japan 2021 (2021/11/1)

40

MIAD (MPLS Indicators and Ancillary Data) に関する要求• Requirements for MPLS Label Stack
Indicators for Ancillary Data
• draft-bocci-mpls-miad-adi-requirements-00• 2021/10/14初版発行• このドラフトでの定義• Ancillary Data (AD)• MPLSパケットに付随するデータであり、フォワードなどの機能に関与する• データは、ラベルスタック内(ISD: Instack Data)だったり、BoS配下(PSD:
Post Stack Data だったり、データ明示的にを伴わない場合(No data)が存在• ADI (Ancillary Data Indicator)• MPLSのスタックに定義され、 Ancillary
Data の存在とタイプを示す識別子• 主な要求(抜粋)• MPLSが定義してきた拡張性・柔軟性・効率性の維持、及び制約・負荷の禁止• SPLが最終手段であることの認識• 非対応装置へ互換性の維持• ADI: ADがラベルスタック内にある or BoS
下にあることが示されること• ADが存在することを示す機能はtop of LSEで運用されること• LER はADIを挿入にあたり、LSRがラベルス
タックを解析し、挿入された場所でADIを処理できるかどうかを判断する機能があること• LSRはADI含まれているか判断できる機能があること• ADのprocessing: fast path; hop-by-hop;
end-to-end いずれもサポートなど

MPLS Japan 2021 (2021/11/1)

41

MIAD 検討(On-going)
詳細は https://trac.ietf.org/trac/mpls/wiki/MIAD 参照• MPLSパケット構成 (個人的見解による、こうなるであろうという概念と課題)
•

•
•

•
•
•

draft-kompellampls-mspl4fa ordraft-song-mpls-ehindicator 相当(?)
新SPLでの定義(?)
MPLS First Nibble(MFN)を新規定義(IANA
での定義必要)既存CWとの互換性考慮
Ancillary Data
TLV定義(?)
Hop by hop 処理 or
End-to-end 処理の区分

Layer 2 header
LabelsFAI(Flag, ISD)

Label
Stack

LabelsBoS Label
PSD header
PSD-specific
data

Embedded packet
MPLS Japan 2021 (2021/11/1)

Payload
FAI: Forwarding Action Indicator
ISD: In stack data
PSD: Post Stack Data
42

まとめ
• ネットワークスライングに関する動向として、IETFでの動向を中心に紹介• IETF Network Slice 動向@TEAS WG• Framework for IETF Network Slices (draft-ietf-teas-ietf-network-slices) 中心に• IETF Network Slice を含めた、MPLSへの応用検討が進むにつれ、
MPLSラベルスタックを見直する動きも活発になったので、MPLSの件についても、これまでの経緯と今議論されている状況を紹介• 特に後者については、 MPLSを用いた新たなネットワーキングやア
プリケーションが生まれるかもしれない、ということにも期待しつつ、
IETF112(11/3, 8-12)以降の展開にも注目したい
MPLS Japan 2021 (2021/11/1)

43

ありがとうございました