80 likes | 105 Views
GMPLS for Ethernet. A Framework for Generalized MPLS (GMPLS) Ethernet draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt. DT Objectives. Define rationales and positioning (incl. applicability) Provide a set of scenarios where GMPLS protocol application is perceived as useful
E N D
GMPLS for Ethernet A Framework for Generalized MPLS (GMPLS) Ethernet draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt
DT Objectives • Define rationales and positioning (incl. applicability) • Provide a set of scenarios where GMPLS protocol application is perceived as useful • Identify requirements in terms of control plane capabilities • Link discovery • Routing • Signaling
DT Non-objectives • End-to-end Ethernet networks • Solve all Ethernet issues (if any) in part. LAN switching environments "The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE, in cooperation with the MPLS WG." • Define data plane forwarding paradigm • Define/Propose RSVP-TE and IGP protocol extensions
Motivations (Major) • Automates provisioning of Ethernet services such as (virtual) private line and LAN services over GMPLS-capable networks • Delivers a range of control plane driven recovery capabilities (example: Spanning Tree Protocol is less suitable in meshed environments then GMPLS control plane driven recovery) • Delivers a homogeneous set of signaling and TE mechanisms for controlling L2 technologies to ease integration towards a common L1/L2/L3 control infrastructure capable of supporting various trust models (e.g. overlay, unified)
Discussion Items • Real interest to have proposed scenarios covered by the CCAMP working (see next slide) ? • Scenario 1: Aggregation • Scenario 2: Metro • Scenario 3: Unified/Core • Scenario 4: Transport/Core
Discussion Items • Real interest to have proposed scenarios covered by the CCAMP working (see next slide) ? • If yes then • Which level of collaboration with “Ethernet world” … and these may have to be considered from multiple perspectives: • Ethernet data plane operation(s) associated to these scenarios (and which scenarios) • Ethernet control plane operation(s) interactions associated to these scenarios (and which scenarios) • Collaboration/Coordination with other WG objectives • Sufficient level of understanding CP impact - in particular: fit in terms of dynamics of operation
Discussion Items • Real interest to have proposed scenarios covered by the CCAMP working (see next slide) ? • If no then • Fallback toward what can be done “today” e.g. port-based • Good candidate for /dev/null • Definition: virtual device that discards all data written to it, and provides no data to any process that reads from it. In Unix programmer jargon, it may also be called the bit bucket or black hole. A controversial posting, for example, might end “Kudos to rasputin@kremlin.org, flames to /dev/null” • … but would like a clear record of it