GMPLScontrolled Ethernet Label Switching GELS BOF

1
GMPLS-controlled Ethernet Label Switching (GELS)
BOF

• IETF 64 - Vancouver - Nov05
• ltloa_at_pi.segt
• ltdpapadimitriou_at_psg.comgt

2
Administrativia

• Blue-sheet
• Note takers (2 1IAB), jabber scribe
• BOF description
• mailing list ltgels_at_rtg.ietf.orggt
• Subscription
• send mail to ltgels-request_at_rtg.ietf.orggt
  (subscribe) in body or subject
• or visit lthttps//rtg.ietf.org/mailman/listinfo/ge
  lsgt
• Archive lthttp//rtg.ietf.org/pipermail/gels/gt
• General information about the mailing list
  lthttps//rtg.ietf.org/mailman/listinfo/gelsgt

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.tx
  t (David Allan)
• o) Label Switched Ethernet (LSE) Architecture -
  10min
• Document draft-jaihyung-ccamp-lse-architectur
  e-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
• lthttp//www.ietf.org/internet-drafts/draft-anderss
  on-gels-bof-prep-01.txtgt

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

Global
MAC
VID
Local
9
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 lthttp//www.ieee802.org/1/gt