80 likes | 195 Views
Service Provider Requirements for Ethe rnet Control with GMPLS. draft-imajuku-ccamp-ethernet-gmpls-req-01.txt. Wataru Imajuku, Muneyoshi Suzuki, and Kazuhiro Matsuda NTT Kenichi Ogaki and Tomohiro Otani KDDI R&D Labs. Nabil Bitar Verizon. Scope of ID.
E N D
Service Provider Requirements for Ethernet Control with GMPLS draft-imajuku-ccamp-ethernet-gmpls-req-01.txt Wataru Imajuku, Muneyoshi Suzuki, and Kazuhiro Matsuda NTT Kenichi Ogaki and Tomohiro Otani KDDI R&D Labs. Nabil Bitar Verizon 70th IETF Vancouver Dec. 2007
Scope of ID • Clarify service provider requirements for basic B-VLAN control over IEEE802.1Qay networks • Scope of IEEE802.1Qay is Traffic Engineering over IEEE802.1ah (B-VLAN) based Ethernet • This ID does not exclude S/C-VLAN control over IEEE802.1ad or .1Q networks, because • IEEE802.1ah networks can include IEEE802.1ad based Ethernet Switches as Backbone Core Bridges (BCBs) • IEEE802.1Qay like implementation is possible even for these IEEE802.1ad based Ethernet Switches • IEEE802.1ah based Ethernet Switch Equipment is expected to support S-tagged IF/C-tagged IF as well as I-tagged IF. 70th IETF Vancouver Dec. 2007
Reference Models (1) • Single layer Eth-Label Switched Network -------- | LSR3 |__ P-based IF -------- ----- _____|(IB-BEB)|__ S-tagged IF P-based IF | LSR1 |____|LSR2 | | |__ I-tagged IF S-tagged IF |(IB-BEB)| |(BCB)| -------- I-tagged IF | | | |_____ -------- -------- ----- | LSR4 | | (B-BEB)| | |__ I-tagged IF -------- | GMPLS Eth-LSP | | (BVID/BMAC) | |<---------------| 70th IETF Vancouver Dec. 2007
Requirements (1) • Control plane architecture and functionalities • Support for in-band control plane channel • Support for automatic neighbor discovery mechanism • Assume hybrid operation with legacy Ethernet • Ethernet Label Switched Path (Eth-LSP) control • Prevention of loops • Service control • Support for control mechanisms of service type at egress port • OA&M • Should capitalize on existing OA&M functionalities • Such as IEEE802.3ag/ITU-T Y.1731 • Link Aggregation • Assume Eth-LSP control over Bandwidth Flexible Links, i.e., Link Aggregation Group (LAG) Links • Support for priority control of Eth-LSPs • Support for re-routing mechanism following change of “Link Bandwidth” • Inter-domain • Support for inter-domain Eth-LSP traversing over various kindsof demarcation points (Facing I-tagged, S-tagged, or C-tagged interfaces). 70th IETF Vancouver Dec. 2007
Reference Models (2) • Multiple layer Eth-Label Switched Network -------- ------ -------- P-based IF __| LSR1 | | LSR2 | | LSR3 |__ P-based IF S-tagged IF __|(IB-BEB)| | (BCB)| |(IB-BEB)|__ S-tagged IF I-tagged IF __| | | | | |__ I-tagged IF -------- ------ -------- | | ||LAG LAG|| ......................|...........|..||..........||................... | | || || ---+---- ------ ------ | LSR A |_____|LSR B |_____|LSR C | | (LSC) | |(LSC) | WDM |(LSC) | -------- ------ ------ | GMPLS Eth-LSP (BVID/BMAC)| |<------------------------>| | O-LSP | | O-LSP | |<--------->| |<-------->| May overlay routing, peer, or augmented model on inter-working architecture. 70th IETF Vancouver Dec. 2007
Requirements (2) • Support for dynamic formation of Link Aggregation Group • Layer 2 GMPLS and Layer 1 GMPLS inter-working • Similar requirements to MPLS-GMPLS inter-work, authored by Kenji et al. • End-to-end signaling of Eth-LSPs • Triggered establishment of L1 LSPs • Selective advertisement of FA into L2 domain • Etc. • Scalability • Number of service ports • Number of bundled S-VLANs mapped to I-SID and Eth-LSPs (Need control of mapping at egress node). • Etc. 70th IETF Vancouver Dec. 2007
Current Status and Issues • Discussion with other service providers • British Telecom • FT Group • Large gap among service providers • Hybrid operation with legacy Ethernet • LAG related requirements • Multi-layer related requirements • Not addressed • P2MP requirements • At this stage, only one service provider has intention to require P2MP GMPLS extension • P&R requirements • Security requirements 70th IETF Vancouver Dec. 2007
Next Step • Bolster and clarify more requirements • Incorporate feedback from other service providers • Establish common requirements and eliminate ambiguity • Establish requirements that consider the reality and feasibility of possible solutions • Possible adoption as a working group document after the next meeting. • Suggestions welcomed 70th IETF Vancouver Dec. 2007