Transcript Schedulable deterministic end-to-end pipes

Schedulable deterministic
end-to-end pipes
Some thought on Control
plane …
Jean-Marc Uze, [email protected]
TNC’06 workshop on “Service Oriented
Optical Networks”, Catania, May 13, 2006
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
1
Discussions on “control plane”
Multiple control plane layers
Copyright © 2005 Juniper Networks, Inc.
Multiple fields
(expertise)
Philosophical
(Politics)
www.juniper.net
2
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
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
3
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
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
4
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)
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
5
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
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
6
same as
before
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)
new
 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
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
7
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 of
MPLS Constraint based routing
(MPLS TE)
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
8
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
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
9
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
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
10
Potential implementation with IETF inter-domain GMPLS TE
Policing
A 21-A31
Path comp
Path
What is missing ?
R1-A21
Path comp
R1
Path
Bw= 100
CT = IP Premium
Path
A11
NREN 1
A21
Policing
Path
A23
A31
Resv
Resv
NREN 2
Resv
A12
A22
Inter-AS TE-LSP R1-R2 : bw = 100m, CT = IP Premium
ASBR-Path: A21-A31-R2
Path
R2
Resv
Resv
A 31-R2
Path comp
NREN 3
A24
A32
 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
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
11
Towards a new layer to handle business relationships
Potentially a Higher Layer Middleware (e.g. GRID)
1
Copyright © 2005 Juniper Networks, Inc.
Business
Business
Layer
Layer
4
4
Network
Network
Management
Management
1
2
3
3
Transport
Transport
Network
Network
www.juniper.net
12
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.)
Copyright © 2005 Juniper Networks, Inc.
www.juniper.net
13
Thanks !!!
And thanks Yakov Rekhter
for his testimony, thoughts and vision on MPLS