gmpls controlled ethernet label switching gels bof l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
GMPLS-controlled Ethernet Label Switching (GELS) BOF PowerPoint Presentation
Download Presentation
GMPLS-controlled Ethernet Label Switching (GELS) BOF

Loading in 2 Seconds...

play fullscreen
1 / 24

GMPLS-controlled Ethernet Label Switching (GELS) BOF - PowerPoint PPT Presentation


  • 313 Views
  • Uploaded on

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:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'GMPLS-controlled Ethernet Label Switching (GELS) BOF' - ostinmannual


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
gmpls controlled ethernet label switching gels bof

GMPLS-controlled Ethernet Label Switching (GELS) BOF

IETF 64 - Vancouver - Nov’05

<loa@pi.se>

<dpapadimitriou@psg.com>

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

objectives and scope
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
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

in scope out of scope
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 scope7
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
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

ethernet frame format s

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

alternative i mpls label
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 |

+---------------+

alterative ii proprietary mac address
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

alternative iii s vid
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

alternative iv new tpid
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

identified dp requirements
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
control plane 1
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
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
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
wg charter proposal orientations
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
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
Open Discussion (40 mins)
  • Please state you name
ieee references
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/>