GMPLS-controlled Ethernet Label Switching

(GELS) BOF

IETF 64 - Vancouver - Nov’05

<loa@pi.se>

<dpapadimitriou@psg.com>

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>

Agendao) Welcome, Administrativia and Agenda Bashing - 5mino) Objectives and Scope - 10mino) 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 - 5mino) Open Discussion - 40mino) 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.1ad802.1ad 802.1ad

LER LSR LER

+---------------+ | Payload | --------------- | Ethernet MAC | --------------- | PHY | +---------------+

Source Dest

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”

<http://www.ietf.org/internet-drafts/draft-andersson-gels-bof-prep-01.txt>

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)

FCSDest

MACAddressSource

MAC Address TC

I

TP

ID

Len

/typ

e

Payload

FCSDest

MACAddressSource

MAC Address Len

/typ

e

Payload

Preamble

Preamble

Alternative I: MPLS label

FCSDest

MACAddressSource

MAC Address MP

LS

E

ther

type

Payload

Pros: supported on most Ethernet switches, well-known standardized “label” format, separation client/networkCons: not really EthernetNote: 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 L

en/t

ype

Payload

Pros: larger label space, MAC_DA based forwardingCons: 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 Lab

el

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

FCSDest

MACAddressSource

MAC Address TC

I: S

-VID

TP

ID: E

thet

ype

Len

/typ

e

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

FCSDest

MACAddressSource

MAC Address TC

I: E

ther

net L

abel

TP

ID: n

ew v

alue

Len

/typ

e

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

IEEE 802.1 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 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/>