1 / 34

The Future of Packet Handling

The Future of Packet Handling. Alan Taylor. The Future of Packet Handling From Internet to Infrastructure. Maintain reliability and quality. Cap. Legacy Data. Legacy Data. Public IP. Grow. New Public Network. Internet. Internet. Cable. Cap. Mobile. Voice. Voice.

donkor
Télécharger la présentation

The Future of Packet Handling

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Future of Packet Handling Alan Taylor

  2. The Future of Packet HandlingFrom Internet to Infrastructure Maintain reliability and quality Cap Legacy Data Legacy Data Public IP Grow New Public Network Internet Internet Cable Cap Mobile Voice Voice Grow IP to Multi-terabit

  3. Agenda • Packet Handling Routing Nodes • Packet Handling across the Network • Diffserv Traffic Engineering • Packet Handling with Optical Paths • GMPLS

  4. Agenda • Packet Handling Routing Nodes • Packet Handling across the Network • Diffserv Traffic Engineering • Packet Handling with Optical Paths • GMPLS

  5. Clean division of tasks Each partition is a consistent interface Light traffic levels across partition Independent scaling design decisions Each block works well within its limits Routing Software OS ForwardingTable Update Packet Processor ForwardingTable Switch Fabric I/O Card I/O Card System Partitioning Optimum System Partitioning #1 #2 #3

  6. Security SNMP Chassis Mgmt Protocols Adjacency Mgmt Operating System Routing Software OS • Purpose built for Internet scale • Optimised for stability as never in forwarding path • Modular design for high reliability • Processes run in their own protected memory space • Modules can be restarted independently and gracefully • Best-in-class routing protocol implementations

  7. Security SNMP Chassis Mgmt Protocols Adjacency Mgmt Operating System Optimised Software Partitioning • Co-Operative Multi-tasking • Process run until finished • Good data consistency • Real time functions poorly served • Pre-Emptive Multi-tasking • Scheduled time slices to each process • UNIX-like kernel operation • Separate real time functions • Not appropriate for shared data functions

  8. Agenda • Packet Handling Routing Nodes • Packet Handling across the Network • Diffserv Traffic Engineering • Packet Handling with Optical Paths • GMPLS

  9. What Is Traffic Engineering? • Ability to control traffic flows in the network • Optimize available resources • Move traffic from IGP path to less congested path Source Destination Traffic Engineering Layer 3 Routing

  10. Traffic Engineering with MPLS • Common IP control plane • Explicitly routed MPLS path • Controlled from ingress using RSVP signalling • Constraint Based Routing extensions to IS-IS or OSPF • Fast Reroute reliability options EgressLSR IngressLSR User defined LSP constraints

  11. Extended IGP Constrained Shortest Path First Traffic Engineering Database (TED) User Constraints Routing Table Explicit Route RSVP Signaling Constraint-Based Routing: Service Model Operations Performed by the Ingress LSR 1) Store information from IGP flooding 2) Store traffic engineering information 3) Examine user defined constraints 4) Calculate the physical path for the LSP 5) Represent path as an explicit route 6) Pass ERO to RSVP for signaling

  12. Constraint-Based Routing Example label-switched-path madrid_to_stockholm{ to Stockholm; from Madrid; admin-group {include red, green} cspf} Stockholm London Paris Munich Geneva Madrid Rome

  13. Diffserv Aware Traffic Engineering • Combines Traffic Engineering with Diffserv • MPLS paths meeting per class service requirements • Constraint Based Routing per Class • Bandwidth constraints per Class • Admission Control per Class over different bandwidth pools • Independent Preemption Priority • Specified in draft-lefaucheur-diff-te-proto-01.txt

  14. Extended IGP Constrained Shortest Path First Traffic Engineering Database (TED) User Constraints Routing Table Explicit Route RSVP Signaling Constraint-Based Routing: Service Model Operations Performed by the Ingress LSR 1) Store information from IGP flooding 2) Store traffic engineering information 3) Examine user defined constraints 4) Calculate the physical path for the LSP 5) Represent path as an explicit route 6) Pass ERO to RSVP for signaling

  15. RSVP Signaling Constraint-Based Routing: Extended IGP • Distributes topology and traffic engineering information • IGP Extensions • Maximum reservable bandwidth per CT • Remaining reservable bandwidth per CT • Link administrative groups (colour) • Mechanisms • Opaque LSAs for OSPF • New TLVs for IS-IS Extended IGP Constrained ShortestPath First (CSPF) Traffic Engineering Database (TED) User Constraints Routing Table Explicit Route

  16. RSVP Signaling Constraint-Based Routing: TED • Maintains traffic engineering information learned from theextended IGP • Contents • Up-to-date networktopology information • Current reservable bandwidth of links per CT • Link administrative groups (colours) Extended IGP Constrained ShortestPath First (CSPF) Traffic Engineering Database (TED) User Constraints Routing Table Explicit Route

  17. RSVP Signaling Constraint-Based Routing: User Constraints • User-defined constraints appliedto path selection • Bandwidth requirements per CT • Hop limitations • Administrative groups (colors) • Priority (setup and hold) • Explicit route (strict or loose) • Overbooking per CT • Preemption Priority for each class Extended IGP Constrained ShortestPath First (CSPF) Traffic Engineering Database (TED) User Constraints Routing Table Explicit Route

  18. RSVP Signaling Constraint-Based Routing: CSPF Algorithm Extended IGP Constrained ShortestPath First (CSPF) Traffic Engineering Database (TED) User Constraints Routing Table For LSP = (highest priority) to (lowest priority) Prune links with insufficient bandwidth for CT Prune links that do not contain an included color Prune links that contain an excluded color Calculate shortest path from ingress to egress Select among equal-cost paths Pass explicit route to RSVP END FOR Explicit Route

  19. Constraint-Based Routing: with DS-TE Seattle Chicago New York San Francisco Kansas City Los Angeles Atlanta label-switched-path SF_to_NY { to New_York; from San_Francisco; CT EF BW 100 MB; } Dallas

  20. Agenda • Packet Handling Routing Nodes • Packet Handling across the Network • Diffserv Traffic Engineering • Packet Handling with Optical Paths • GMPLS

  21. The Emerging Two-Layer Network • Packet Routing Layer provides- • Any-to-any datagram connectivity • Packet Processing granularity • Class of Service classification and handling • IP service delivery • Optical Layer provides flexible optical bandwidth • Dynamic provisioning of optical bandwidth provides growth and innovative service creation IP Service (Routers) Optical Core Optical Transport (OXCs, WDMs)

  22. Generalized MPLS • Extends MPLS control plane to support multiple switching types • Packet switching • TDM switching (SONET/SDH) • Wavelength switching (lambda) • Physical port switching (fiber) • GMPLS sets up LSPs of a particular type (therefore between like devices / ports) • Eg, Router-to-Router using TDM or l-switch; • Or, TDM-to-TDM using l-switch; • Etc.

  23. Generalized MPLS • Uses existing and evolving technologies • Based on IP routing and signaling • Builds on MPLS, and includes MPLS • Distinction: packet vs. non-packet MPLS • Is not a protocol, but a suite of protocols • Just as MPLS is not a protocol • Facilitates parallel evolution in the IP and transmission domains • “Supports” peer and overlay models

  24. Overlay and Peer Models • Overlay model • Two independent control planes • IP/MPLS routing • Optical domain routing • Router is client of optical domain • Optical topology invisible to routers • Peer model • Single integrated control plane • Router and optical switches are peers • Optical topology is visible to routers ?

  25. GMPLS Mechanisms • Extensions to OSPF and IS-IS • Forwarding adjacency • LSP hierarchy • Constraint-based routing • Signaling extensions • Link Management Protocol (LMP) • Link bundling

  26. GMPLS: IGP Extensions • ISIS extensions to carry GMPLS information • New sub-TLVs for Extended IS Reachability TLV • Outgoing/Incoming Interface Identifier • Maximum LSP Bandwidth • Link protection • New TLVs • Link descriptor (encoding and transmission rate) • Shared risk link group (list of SRLGs) • Defined in draft-ietf-isis-gmpls-extensions-09.txt

  27. GMPLS: IGP Extensions • OSPF extensions to carry GMPLS information • New sub-TLVs for the Link TLV within the TE Opaque LSA • Outgoing/Incoming Interface Identifier • Link protection type • Link descriptor (encoding and transmission rate) • Shared risk link group (list of SRLGs) • Maximum LSP bandwidth sub-TLV (replaces maximum link bandwidth) • Defined in draft-ietf-ccamp-ospf-gmpls-extensions-05.txt

  28. Ingress Node (low order LSP) Egress Node (low order LSP) FA-LSP Ingress Node (high order LSP) Egress Node (high order LSP) GMPLS: Forwarding Adjacency • A node can advertise an LSP into IGP • Establish LSP using RSVP/CR-LDP signaling • IGP floods FA-LSP • Link state database and traffic engineering database maintains conventional links & FA-LSPs • A second node wanting to create an LSP can use an FA-LSP as a”link” in the path for a new lower order LSP • The second node uses RSVP to establish label bindings for the lower order LSP SONET/SDH ADM SONET/SDH ADM ATM Switch ATM Switch

  29. GMPLS: LSP Hierarchy • Improves scalability through LSP aggregation • Packet capable links can support multiple levels via label stacking • Allows hierarchy of link aggregation mechanisms • LSPs always start and terminate on similar interface types • Achieved via construction of LSP regions PSC Cloud TDM Cloud LSC Cloud LSC Cloud TDM Cloud PSC Cloud FSC Cloud Fiber 1 Bundle Fiber n FA-PSC FA-TDM FA-LSC Explicit Label LSPs Time-slot LSPs Time-slot LSPs Explicit Label LSPs l LSPs l LSPs Fiber LSPs (multiplex low-order LSPs) (demultiplex low-order LSPs)

  30. Extended IGP Routing Table GMPLS: Constraint-Based Routing • Reduce the level ofmanual configuration • Input to CSPF: • Path performance constraints • Resource availability • Topology information (including FA-LSPs) • Output: Explicit routefor GMPLS signaling Traffic Engineering Database (TED) Constrained ShortestPath First (CSPF) User Constraints Explicit Route RSVP Signaling

  31. PATH RESV GMPLS: RSVP Signaling Extensions • Label Related Formats • Generalized Label Request • Link Protection Type • LSP Encoding Type • Generalized Label Object supports implicit TDM, λ, or fiber labels • Suggested Label • Label Set • Support for bidirectional LSPs SONET/SDH ADM SONET/SDH ADM

  32. GMPLS: Link Management Protocol • Core functions of the Link Management Protocol • Control channel management • Link property correlation • Additional tools specified for LMP • Link connectivity verification • Fault isolation • See draft-ietf-ccamp-lmp-03.txt LMP LMP LMP LMP

  33. Conclusion • Routing Nodes based on clean and consistent partitioning • Hardware and software • Handling different traffic classes across the Network • Diffserv Traffic Engineering • Routing Layer interaction with Optical Paths • GMPLS

  34. Thank You http://www.juniper.net

More Related