schedulable deterministic end to end pipes some thought on control plane n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Schedulable deterministic end-to-end pipes Some thought on Control plane … PowerPoint Presentation
Download Presentation
Schedulable deterministic end-to-end pipes Some thought on Control plane …

Loading in 2 Seconds...

play fullscreen
1 / 14

Schedulable deterministic end-to-end pipes Some thought on Control plane … - PowerPoint PPT Presentation


  • 84 Views
  • Uploaded on

Schedulable deterministic end-to-end pipes Some thought on Control plane …. Jean-Marc Uze, uze@juniper.net TNC’06 workshop on “Service Oriented Optical Networks”, Catania, May 13, 2006. Multiple control plane layers. Multiple fields (expertise). Philosophical (Politics).

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 'Schedulable deterministic end-to-end pipes Some thought on Control plane …' - harriet-raymond


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
schedulable deterministic end to end pipes some thought on control plane

Schedulable deterministic end-to-end pipesSome thought on Control plane …

Jean-Marc Uze, uze@juniper.net

TNC’06 workshop on “Service Oriented Optical Networks”, Catania, May 13, 2006

discussions on control plane

Multiple control plane layers

Multiple fields

(expertise)

Philosophical

(Politics)

Discussions on “control plane”

middleware

GMPLS(s)

signaling

AAA

lambda

GRID

VPNs

services

agenda
Agenda
  • Mid 90s - Common control plane motivations
  • Towards a common control plane – early attempts
  • 1995-96 - From early attempts to Tag Switching to MPLS
  • late 1990s: From MPLS to GMPLS
  • Multiple control plane layers
  • Conclusion
mid 90s common control plane motivations
Mid 90s: Common control plane motivations
  • The problem: price/performance of routers
  • Solution: use ATM switches instead of routers
  • Control Plane initial choice:
    • The overlay Model
    • ATM Core as an IP subnetwork
    • Full mesh of PVCs among router
    • Two separate (very different) control planes
overlay lessons learned
Overlay - Lessons learned
  • What’s wrong with the overlay model ?
    • How to handle (redundant) functionality?
    • How to support routing peering hierarchy (needed for scalability) among the routers connected to an ATM network ?
      • ATMARP, MARS, NHRP, LEC, LES, LECS, BUS, etc… trying to bring the two together. Either fairly complex, or broken, or both…
  • Use of the overlay model requires careful considerations of interactions between control planes
    • Enabling the same functionality at multiple layers of network may produce quite a few surprises
    • What is the proper layer of network for a particular functionality ?
  • Large scale overlay does not fit well with the IP control plane (due to the large number of IP routing adjacencies)
towards a common control plane early attempts
Towards a common control plane – early attempts
  • Problem: Can both routers and ATM switches be controlled by a common control plane ? - Yes
  • Solution: Extend IP control plane to control ATM switches - common control plane that spans both routers and ATM switches
    • CSR by Toshiba and IP switching by Ipsilon
    • Key Features:
      • IP based control plane, Forwarding state (VCI/VPI) at the granularity of individual TCP flows or host source/destination pairs
      • Short-lived flows forwarded using control plane resources, Long-lived flows forwarded using data plane resources (ATM data plane)
      • Control plane creates/maintains forwarding state (ATM VCI/VPI) in response to data plane traffic
  • BUT
    • Unscalability of forwarding granularity to TCP flows or host source/destination for large scale Internet.
    • Data-driven establishment of forwarding state creates interference with the control plane
from early attempts to tag switching to mpls mpls main ideas

same as before

new

From early attempts to Tag Switching to MPLS - MPLS main ideas
  • Separate forwarding information (label) from the content of IP header
  • IP based control plane (OSPF, ISIS, BGP, RSVP, etc…)
  • Multiple link-specific realizations of the label swapping forwarding paradigm
    • Label swapping is for routers too (not just for ATM switches)
  • Forwarding Equivalence Classes (FECs):
    • Groups of packets forwarded over the same Label Switched Path (LSP)
    • As a packet enters an MPLS network, it is assigned a label based on its Forwarding Equivalence Class (FEC)
      • as determined at the edge of the MPLS network
    • Wide range of forwarding granularities due to the flexibility of forming Forwarding Equivalence Classes (FECs)
  • Forwarding hierarchy via label stacking
  • Control traffic driven creation of forwarding state
from mpls to gmpls
From MPLS to GMPLS
  • Justification for ATM switches to interconnect routers faded away
  • But OXCs and TDM cross-connects arrived, and without a standard-based control plane
  • “G” in GMPLS stands for “generalized”
    • Many commonalities with MPLS
    • What is generalized: label, constraints, separation of control and data plane (out-of-band control plane)
  • GMPLS is not a superset of MPLS
  • GMPLS is a proper superset ofMPLS Constraint based routing(MPLS TE)
gmpls what is new for packet based lsps
GMPLS – what is new for packet-based LSPs ?
  • Bidirectional LSPs
  • Unnumbered links
  • Link bundling
  • LSP hierarchy (forwarding adjacencies)
    • Improves control and data plane scalability
    • Regions based on “colors”, routing areas, ASs
  • Multi-region LSP (multi-area, multi-AS)
  • GMPLS – technology push vs market pull
    • High demand of bandwidth: Dot-com bubble burst revealed the mismatch between the assumptions about bandwidth demand and the reality
    • Recently started to gain more market attention, due to the continuous growth of bandwidth demand. Was a bit ahead of its time at the time of creation – its time seems to have come now
gmpls lessons learned
GMPLS – lessons learned
  • Generalization is a very powerful concept !!!
  • Try to build solutions to new problems by generalizing the existing solutions, rather than develop new solutions
    • By focusing on what is common
    • By generalizing the existing concepts/models/mechanisms
  • If new solutions have to be developed, try to avoid point solutions – design new solutions with the generalization in mind
potential implementation with ietf inter domain gmpls te

Path

Path

Path

Path

Path

Bw= 100

CT = IP Premium

Resv

Resv

Resv

Resv

Resv

Inter-AS TE-LSP R1-R2 : bw = 100m, CT = IP PremiumASBR-Path: A21-A31-R2

Potential implementation with IETF inter-domain GMPLS TE

Policing

Policing

A 21-A31

Path comp

A 31-R2

Path comp

What is missing ?

  • GMPLS TE is originally intra-domain (RSVP-TE with routing IGP TE extensions)
  • Inter-domain GMPLS TE extends signaling and routing protocols to set-up an LSP across multiple providers
  • Need for proper policing and filtering of RSVP-TE messages at NREN boundaries
    • Filter/modify QoS parameters
  • Need for scheduling
  • In this example the Path Computation is performed per domain (route expansion)
    • Need for Provider-chain selection based on NRENs business relationship

NREN 2

R1-A21

Path comp

NREN 1

NREN 3

A31

A11

A23

A21

R2

R1

A32

A24

A12

A22

towards a new layer to handle business relationships

QoS?Reliability?Security?

Business

Layer

Business

Layer

4

4

1

2

1

3

3

Towards a new layer to handle business relationships

Potentially a Higher Layer Middleware (e.g. GRID)

NetworkManagement

NetworkManagement

TransportNetwork

TransportNetwork

conclusion
Conclusion
  • R&E community implements what prefigures future Internet networks
    • Opportunity: contribute to standardization bodies on this new business or service layer (e.g. IPsphere Forum). Please join the TNC session 6c on Wednesday, on “Networks on Networks - Grids”)
      • Do not build technology that will be used just by a private “club” (there could be several clubs)
    • Try to solve all on-demand services issue, not only optical services
  • Carriers are not completely different from R&E networks
    • Key difference: profitability
    • Key commonalities:
      • Need for dynamic end-to-end services across multiples network, triggered by application
      • Need of COTS equipment and standards. The difference is how this technology is implemented (use cases, fast, scale, operations etc.)