GMPLS-controlled Ethernet Label Switching (GELS) BOF

1. GMPLS-controlled Ethernet Label Switching (GELS) BOF IETF 64 - Vancouver - Nov’05 <loa@pi.se> <dpapadimitriou@psg.com>

2. Administrativia • Blue-sheet • Note takers (2 + 1IAB), jabber scribe • BOF description • mailing list: <gels@rtg.ietf.org> • Subscription: • send mail to <gels-request@rtg.ietf.org> (subscribe) in body or subject • or visit <https://rtg.ietf.org/mailman/listinfo/gels> • Archive: <http://rtg.ietf.org/pipermail/gels/> • General information about the mailing list: <https://rtg.ietf.org/mailman/listinfo/gels>

3. Agenda o) Welcome, Administrativia and Agenda Bashing - 5min o) Objectives and Scope - 10min o) Data Plane and Cooperation with IEEE - 20min - Data Plane Requirements - Positioning of Ethernet Label Switching - IEEE 802.1 overview (Paul Condon) - IEEE liaison process (Bernard Adoba) o) Control Plane and Cooperation with IETF WGs - 15min - Control Plane Requirements - Positioning in IETF and Routing Area - Relationship with CCAMP WG (Adrian Farrel) o) GMPLS Control of Ethernet IVL Switches - 10min Document: draft-fedyk-gmpls-ethernet-ivl-00.txt (David Allan) o) Label Switched Ethernet (LSE) Architecture - 10min Document: draft-jaihyung-ccamp-lse-architecture-00.txt (Jaihyung Cho) o) WG Charter Proposal and Bashing - 5min o) Open Discussion - 40min o) Summary and Next Steps - 5min ~10min

4. Objectives and Scope • Determine community interest in applying GMPLS control plane to Ethernet LSR • Gauge whether there is cause and support for this work within the IETF • Highlight and discuss foreseen interactions with other SDOs, in particular, the IEEE 802.1, with respect to the foreseen data plane operations • Discuss the GMPLS control plane impact and requirements and what extensions to existing GMPLS protocols may be required

5. Scope o) Ethernet LER: take an incoming Ethernet frame and add or remove the Ethernet label o) Ethernet LSR: take an incoming labeled Ethernet frame and swap the Ethernet label o) Ethernet point-to-point LSP +---------------+ | Payload | --------------- | Ethernet MAC | --------------- | PHY | +---------------+ LER LSR LER Source Dest 802.1ad 802.1ad 802.1ad

6. In Scope - Out of Scope • In Scope • Setting up, removing, managing and operating Point-to-point (P2P) Traffic engineered Ethernet LSPs • Defining format and value space for Ethernet labels • As much as possible environment agnostic - keeping control-driven paradigm in place - • Out of Scope • GMPLS Ethernet LSPs to the customer premises and/or to hosts • GMPLS Ethernet Label Switching in campus networks as well as mobile and wireless networks • Both Traffic Engineered and non-Traffic Engineered point-to-multipoint LSPs • Changes to the Ethernet data plane • To the extent such changes are necessary they need to be achieved through the mechanisms defined by the IEEE

7. Objectives and Scope BOF Preparation document: • “Use of the GMPLS control plane for point-to-point Ethernet Label Switching” <http://www.ietf.org/internet-drafts/draft-andersson-gels-bof-prep-01.txt>

8. Data Plane Global • Definition of the “label space” • Scope • Local • Global • Encoding • Ethernet frame header • MAC address field e.g. MAC_DA • TAG field (VID) e.g. S-VID • Combination ? • Shim header • Discussion of the identified alternatives • Note: a new candidate in the loop (see Dave) VID MAC Local

9. FCS Len/type Dest MACAddress Source MAC Address Payload Ethernet Frame Format(s) Preamble FCS Len/type Dest MACAddress Source MAC Address TPID TCI Preamble Payload

10. Alternative I: MPLS label MPLS Ethertype Dest MACAddress Source MAC Address Preamble FCS Payload Pros: supported on most Ethernet switches, well-known standardized “label” format, separation client/network Cons: not really Ethernet Note: encapsulation/decapsulation of Ethernet frame at each node +---------------+ | Ethernet MAC | --------------- | Label | --------------- | Ethernet MAC | +---------------+

11. Alterative II: Proprietary MAC Address FCS Len/type Label Source MAC Address Preamble OUI Payload Dest MACAddress Pros: larger label space, MAC_DA based forwarding Cons: requires re-writing of source and dest. MAC-addresses once the frame enters/leaves the network (asymmetric encoding between the MAC_SA and MAC_DA), changes processing of this field compared to its current usage. Note: interoperability with existing Ethernet switches and with switches that are both GMPLS and non-GMPLS controlled

12. Alternative III: S-VID TPID: Ethetype FCS TCI: S-VID Len/type Dest MACAddress Source MAC Address Preamble Payload Pros: S-VID processing supported on most Ethernet switches, relatively simple approach Cons: label space size (but is that a real issue ?), interoperability with non-GMPLS Ethernet switches Note: makes use of the S-VID translation functionality

13. Alternative IV: new TPID TCI: Ethernet Label TPID: new value FCS Len/type Dest MACAddress Source MAC Address Preamble Payload Pros: No change of existing VID space (C-/S-VID) non-GMPLS switches just drop, relatively simple approach Cons: label space size (but is that a real issue ?), may require specific work in order to address frame forwarding

14. Identified DP Requirements • Ethernet MAC frame structure must be left unchanged i.e. composed by Ethernet MAC frame header, a Payload and an FCS • Ethernet MAC frame header must remain structured such as to include the MAC_DA, MAC_SA one or more TAGs and the EtherType • Ethernet TAG must still include a TPID (TAG Protocol ID) and a TCI (TAG Control Information) • Physical medium over which Ethernet labeled frames could be transmitted are left unchanged and be forward compatible with IEEE 802.3 • MAC address space, size (6 bytes), format and semantic are left unchanged and must still support unicast, multicast and broadcast format and semantic • Ethernet label format and switching must be such as to leave IEEE 802.1ag CFM operations independent • MTU size: the size of the Ethernet labeled frame falls into the revision of the IEEE P802.3as Ethernet Frame Expansion

15. IEEE 802.1 Overview • Paul

16. IEEE Liaison Process • Bernard

17. Control Plane (1) • Identified Generic Requirements = applicable independently of the label space definition and processing: • Re-/use TE methods defined for G/MPLS • Re-/use recovery methods defined for G/MPLS • GMPLS is based on the IP routing and addressing models, in part. IPv4 and/or IPv6 addresses are used to identify L2SC interfaces • Scalability enhancements to addressing (e.g. unnumbered and bundled links) must be re-usable as it is not viable to associate an IP address with each end of each L2SC interface • GMPLS control plane information exchange between adjacent Ethernet LSRs and control plane information processing must be independent of the IP control channel implementation • Control plane resilience mechanisms defined for GMPLS control plane (e.g. RSVP engine graceful restart) must be re-usable for Ethernet LSR

18. Control Plane (2) • Link Discovery • Aggregation of multiple data links into a single TE Link and synchronize their properties • Verify data links physical connectivity and verify the mapping of the Interface ID to Link ID and their local-remote associations • Optionally, fault management may be provided to suppress alarms and localize failures. • Extensions to LMP may be required • Routing Advertisement and Traffic Engineering • Routing instance should treat the broadcast point-to-point control channel between adjacent LSRs as a point-to-point circuit • Exchange of reachability information • Exchange of traffic engineering information

19. Control Plane (3) • Signaling: GMPLS RSVP-TE Feature Set • Ethernet Traffic Parameters • Ethernet Label Request • Ethernet Label: L2 labels are context sensitive • interpretation of the received label depends on the type of the link [X,L2SC], [L2SC,L2SC], [L2SC,X] over which the label is used. • The received label MUST be interpreted according the requestor traffic parameters i.e. a label by itself does not allow knowing the detailed properties of the L2 LSP being requested • bi-directional L2 LSPs are indicated by the presence of an upstream label in the Path message. • Explicit and Record Routing support

20. Relationship with CCAMP WG • Adrian

21. WG Charter Proposal - Orientations • Work scope: • Ethernet networks (aggregation/core agnostic) with a GMPLS control plane • Work items: • Definition of Ethernet label value space and processing • Definition of protocol-independent attributes for describing links and paths that are required for routing and signaling Ethernet switched point-to-point paths • Specification of routing protocol extensions (OSPF, ISIS) and signalling protocol extensions (RSVP-TE) required for Ethernet switched point-to-point path establishment • Definition of MIB modules and other OAM techniques • Cooperation is foreseen with the following IETF Working Groups (in addition to the CCAMP WG): OSPF WG, IS-IS WG, MPLS WG and TRILL WG. • Cooperation is foreseen with IEEE 802.1

22. WG Charter Proposal - Steps/Milestones • Step 0: Requirement document • Step 1: Framework • Terminology • Architecture • Step 2: decision on the Ethernet label(s) format • Step 3: Signaling and Routing Extensions • Step 4: OAM features and MIB • Step 5: Signaling and Routing Applicability input

23. Open Discussion (40 mins) • Please state you name

24. IEEE References • IEEE P802.1D/D4, Media Access Control (MAC) Bridges, October 2003. • IEEE P802.1Q-REV/D5.0, Virtual Bridged Local Area Networks, September 2005. • IEEE P802.1AD/D6.0, Virtual Bridged Local Area Networks, August 2005. Amendment 4: Provider Bridges • IEEE P802.1AH/D1.2, Virtual Bridged Local Area Networks, August 2005. Amendment 6: Provider Backbone Bridges • Note: for information on the availability of IEEE Documents, please see <http://www.ieee802.org/1/>