GMPLS-controlled Ethernet Label Switching (GELS) BOF IETF 64 - Vancouver - Nov’05

Administrativia Blue-sheet Note takers (2 + 1IAB), jabber scribe BOF description mailing list: –Subscription: send mail to (subscribe) in body or subject or visit –Archive: –General information about the mailing list:

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 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

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

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 802.1ad LERLSRLER | Payload | | Ethernet MAC | | PHY | SourceDest

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

Objectives and Scope BOF Preparation document: –“Use of the GMPLS control plane for point-to-point Ethernet Label Switching”

Data Plane 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) MACVID Local Global

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

Alternative I: MPLS label FCS Dest MACAddress Source MAC Address MPLS Ethertype 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 Preamble | Ethernet MAC | | Label | | Ethernet MAC |

Alterative II: Proprietary MAC Address FCS Dest MACAddress Source MAC Address Len/type Payload 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 Preamble OUI Label

Alternative III: S-VID 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 FCS Dest MACAddress Source MAC Address TCI: S-VID TPID: Ethetype Len/type Payload Preamble

Alternative IV: new TPID 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 FCS Dest MACAddress Source MAC Address TCI: Ethernet Label TPID: new value Len/type Payload Preamble

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 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

IEEE Overview Paul

IEEE Liaison Process Bernard

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

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

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

Relationship with CCAMP WG Adrian

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

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

Open Discussion (40 mins) Please state you name

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