1 / 40

Life is about a lot of choices

GMPLS controlled Ethernet Loa Andersson Acreo AB loa@pi.se MPLS wg co-chair Internet Architecture Board. Life is about a lot of choices. “To Traffic Engineer or not Traffic Engineer, that’s the…?” If GMPLS is all about Traffic Engineering, what is Traffic Engineering about?.

gallia
Download Presentation

Life is about a lot of choices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GMPLS controlled Ethernet Loa AnderssonAcreo ABloa@pi.seMPLS wg co-chairInternet Architecture Board

  2. Life is about a lot of choices • “To Traffic Engineer or not Traffic Engineer, that’s the…?” • If GMPLS is all about Traffic Engineering, what is Traffic Engineering about?

  3. (G)MPLS Traffic Engineering tools • Consraint Based routing • Explicit routes • QoS • Protection • Fast re-route • Detour / local repair • Alternate paths • Resources • Improved Utilization • Traffic where resources are • Less congestion • Network performance • Traffic aggregates

  4. Ethernet and TE • If Traffic Engineering is good for IP networks… • … and is good for optical networks • Then why is it not good for Ethernet networks?

  5. 0-th order approximation:Control Plane Terminology • Single Layer Control Plane • Common Control Plane • Integrated (dp : cp = 1:N) • Augmented (dp : cp = 1:1) • Unified Control Plane • “The God box(es)” • Centralized (cp : nodes = 1:N) • Distributed (cp : nodes = 1:1)

  6. The integrated GMPLS approach LSR LSR LSR LSR LSR LSR Control Plane OSPF-TE OSPF-TE OSPF-TE OSPF-TE OSPF-TE RSVP-TE RSVP-TE RSVP-TE RSVP-TE RSVP-TE Layer n Layer n LSP Layer n-1 Data Plane Layer n-1 LSP Layer n-2 Layer n-2 LSP

  7. ISP (access) ISP(core) Service Reference Model Service “User” SP Access Product Traffic exchange Legend: Service is the agreement between end-user and the Service Provider (end-2-end) Access is the agreement that exists between end-user and his ISP, necessary to access services Traffic Exchange is the agreement between two ISPs Product is the is the agreement between a service provide, necessary to deliver services ISP (access) is the architecture of the access networks ISP (core) is the architecture of the core networks

  8. Place of GMPLS controlled Ethernet(Maximalistic) Service “User” SP Access Product ISP(core) ISP (access) Traffic exchange

  9. GMPLS controlled Ethernet (BoF) Service “User” SP Access Product ISP(core) ISP (access) Traffic exchange

  10. The MPLS Label 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Label | Entry Label: +-+-+-+-+-+-+-+-+ Label Value, 20 bits | Label | Exp: Experimental Use +-+-+-+-+-+-+-+-+ 3 bits | Label | Exp |S| S: Bottom of Stack +-+-+-+-+-+-+-+-+ 1 bit | TTL | TTL: Time to Live +-+-+-+-+-+-+-+-+ 8 bits

  11. L2 Frame Payload Where does the label ride? IP- header Label

  12. OK – but what about Ethernet? • Ethernet is Eternal … • … but ever changing! • Started as a campus technology (one of many) • Today it has entered into provider core networks.

  13. L2 access Q-tag CPE CE Networking architecture P MPLS PE

  14. … depends on perspective P MPLS PE L2 access Q-tag CPE CE

  15. L2 access Q-tag CPE CE Why not? GMPLS PE

  16. GMPLS Ethernet Label Switching GMPLS PE L2 access Q-tag CPE CE

  17. P Even better GMPLS L2 access Q-tag CPE CE

  18. An Ethernet Label … • … what’s that? • IP-label = MPLS Label • FR-label = DLCI • ATM-Label = VPI/VCI • SDH-label = time slot • Optical-label = lambda • Port-label = switch port • => A GMPLS Label is by definition inherent to the switching technology

  19. Ethernet label - six proposals • Four with common denominators • Rides in the Ethernet framing • Two defined according to IEEE rules and traditions • True Ethernet labels • Two that don’t • MPLS labels • Proxy Ethernet labels • Innovative phase

  20. The IETF relations to other SDOs • Guiding principle • Respect protocol and technology ownership • Don’t do anything that requires changes to the data plane(IEEE will approve the data plane, when this happens we will take advantages of this • IETF will do Ethernet control plane only, i.e. extensions to OSPF-TE and RSVP-TE (possibly also LMP) • Will review proposals according to these principles.

  21. Frame Check Sequence Len/type Dest MACAddress Source MAC Address Payload Ethernet frame format(s) Preamble Frame Check Sequence Len/type Dest MACAddress Source MAC Address Q-tag tpid Preamble Payload

  22. The odd-ball - alterative I • Use an MPLS-label - 1 MPLS Ethertype Frame Check Sequence Dest MACAddress Source MAC Address Preamble Payload Pros – most switches can handle it, well-known format, TTL Cons – not Ethernet, recreate Ethernet at each node, and possiblywon’t work

  23. E-rtype Use a shim header – alternative II • Use an MPLS-label - 2 DestMACAddress MPLS E-rtype DestMACAddress Preamble FCS Preamble PL Source MAC Address Source MAC Address MPLS label Pros – simple Cons – clumsy

  24. Proprietary DA - alterative III • Use an Proprietary MAC address Frame Check Sequence Len/type Label Source MAC Address Preamble OUI Payload Dest MACAddress Pros – large label space, Ethernet Cons – what happens if…, not link local

  25. VLANid - alterative IV • Use the VLANid Q-tag (Ethernet label) IEEE802.1 VLAN Frame Check Sequence Len/type Dest MACAddress Source MAC Address Preamble Payload tpid Pros – easy, just literature (possibly only a BCP) Cons – takes away the VLANs, inter-op with non-GMPLS switches?

  26. New tpid - alterative V • Use a new tpid IEEE802.1 Ethernet Label Ethernet Label Frame Check Sequence Len/type Dest MACAddress Source MAC Address Preamble Payload tpid Pros – Ethernet, VLANs possible, non-GMPLS switches just drop Cons – “changes data plane”

  27. VLANid - alterative VI • Use the VLANid + Dest Address (48+12 bits) Q-tag (Ethernet label) IEEE802.1 VLAN Frame Check Sequence Len/type Dest MACAddress Source MAC Address Preamble Payload tpid Pros – large and domain wide label Cons – domain wide label

  28. What is possible, what will we do? • Proposal – 1 • MPLS label 1, IETF owns technology, but this won’t work • Proposal – 2 • MPLS label 2, IETF owns technology, will work • Proposal – 3 • Proprietary MAC-address, IEEE technology, changes data plane, won’t fly

  29. What is possible, what will we do? • Proposal – 4 • VLAN-Id , IEEE owns technology, but IEEE seems to favoring this proposal • Proposal – 5 • New tpid, IEEE owns technology, IEEE is “reluctant”, there is a differences from “what switches can” and “what is standard” • Proposal – 6 • MAC-address + VLAN-Id, IEEE technology, changes data plane, won’t fly

  30. Hmmm!!! • Yes there is a seventh proposal … • … and an eighth! • Common denominator is that they changes the Ethernet data plane! • There is a difference between “standard” and “what every Ethernet switch ca do” • Really need to get into a consolidating phase

  31. What is next? • Will try to converge on proposal 2 or 4, MPLS label or VLAN • Will accept IEEE guidance in this process • Extensions to 802.1ad gives (decision in december) • label swapping • per platform labels • => to per interface lables • In “IEEE speak”: Per component VLAN translation

  32. Two discussion (I) • Do we want to do this at all? • Ethernet don’t need a control plane • Way to complex • Changes the Ethernet data plane • Makes my head ache • Will never work

  33. Two discussion (II) • How do we want to do this? • Scenarios • Which label • Can’t change data plane • What about IEEE?

  34. Status • BoF in Vancouver • draft-andersson-gels-bof-prep-01.txt • Not baked ready yet – the plethora of proposals were confusing • New BoF required • More focus, better backing

  35. Status • Acreo have an implementation • New tpid • 13 bit label • Linux based and the Dragon project • Runs on the SwitchCore chip • Interworks with Transmode XC and Juniper routers

  36. Layer3 router Layer3 router Layer2 switch Lambda switch Lambda switch Layer2 switch Layer3 router Layer3 router R1 S1 L1 L2 S2 R2 LER 2 LSP3 (Lambda Switch Capable LSP) LSP1 (IP/Layer 3 LSP) LSP2 (Layer-2 Switch Capable LSP) Implementation guide

  37. OSPF-TE Dragon SwitchCore What have we implemented? Acreo GELS RSVP-TE Dragon Acreo GELS

  38. Switching levels EthLSR OptLSR OptLSR EthLSR LSR LSR LSR LSR LSC LSC LSC-bis PSC PSC L2SC L2SC

  39. Demo-network data-plane (gels) GMPLS Ethernet LSPs IP Linux SwitchCore Linux

  40. End of presentation  • Questions?

More Related