1 / 18

Don Fedyk, Nortel Networks Anoop Ghanwani, Nortel Networks Rajesh Balay, Cosine Communications

Multiple Metrics for Traffic Engineering with IS-IS and OSPF draft-fedyk-isis-ospf-te-metrics-00.txt. Don Fedyk, Nortel Networks Anoop Ghanwani, Nortel Networks Rajesh Balay, Cosine Communications. Multiple Metrics for Traffic Engineering.

seven
Download Presentation

Don Fedyk, Nortel Networks Anoop Ghanwani, Nortel Networks Rajesh Balay, Cosine Communications

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. Multiple Metrics for Traffic Engineeringwith IS-IS and OSPFdraft-fedyk-isis-ospf-te-metrics-00.txt Don Fedyk, Nortel Networks Anoop Ghanwani, Nortel Networks Rajesh Balay, Cosine Communications

  2. Multiple Metrics for Traffic Engineering • There is a need for more than one metric for traffic engineering • MPLS TE path selection makes efficient use of multiple metrics • A different metric may be used for an LSP • Administrative cost • Delay • Bandwidth • Hop count • Delay-jitter • Loss or error probability • Economic cost • Others? The main desire is to have a delay metric option

  3. Recommendation for Advertising Multiple Metrics • Currently have one TE metric and a set of link attributes • Default TE metric • Bandwidth reserved at holding priority • Maximum link bandwidth • Maximum reservable bandwidth • Resource class or color • Expand the TLV to advertise up to three additional metrics • Support for one or more of these is optional • Up to four TE metrics total

  4. Proposed Encoding for the Metrics • For IS-IS • The optional metrics are sub-TLVs carried within the Extended IS Reachability TLV, whose TLV type is 22 • Traffic Engineering Optional Metric 1 (sub-TLV type 19, length 3 octets) • Traffic Engineering Optional Metric 2 (sub-TLV type 20, length 3 octets) • Traffic Engineering Optional Metric 3 (sub-TLV type 21, length 3 octets) • For OSPF • The optional metrics are sub-TLVs carried within the Link TLV, whose TLV type is 2 • Traffic Engineering Optional Metric 1 (sub-TLV type 10, length 4 octets) • Traffic Engineering Optional Metric 2 (sub-TLV type 11, length 4 octets) • Traffic Engineering Optional Metric 3 (sub-TLV type 12, length 4 octets)

  5. Why Are the Actual Metrics Left Undefined? • Different metrics will be important to different service providers • Standardizing each metric separately would mean a constant process of standardizing new TLVs every time a new metric is desired • Using this proposal new metrics can be introduced in the network (or removed) easily by configuration without the need for changing routing code This is common practice for metrics

  6. Next Steps • This proposal is an update of a draft presented in Washington • We would like to see this work adopted as a Working Group document in the IS-IS and OSPF WGs • What is the status of the TE documents in the OSPF and IS-IS WGs?

  7. Extensions to OSPF/IS-IS for Optical Routing

  8. draft-wang-ospf-isis-lambda-te-routing-00.txt Guoqiang Wang, Don Fedyk (Nortel Networks) Vishal Sharma, Ken Owens (Tellabs) Gerald R. Ash (AT&T) Murali Krishnaswamy, Yang Cao (Lucent Technologies) M.K. Girish (SBC Technology Resources, Inc.) Herbert M. Ruck (Packet Network Services) Simon Bernstein, Phuc Nquyen (Global One) Sunil Ahluwalia (Trillium Digital Systems) Lihshin Wang(Qwest Communications) Avri Doria (Nokia Telecommunications) Heinrich Hummel (Siemens AG)

  9. Layered View • L1, L2, and L3 each have a service, data (forwarding), and control. • Restoration and protection mechanisms are also present at each layer. Service Forwarding Control • Best effort IP connectionless • Hop-by-hop IP connectionless • IP Routing (OSFP) • ARP L3 • ATM UNI connection oriented • Label switching • PNNI, PVC • call control L2 • Fixed b/w transparent bit service • Electrical cross connect • Optical cross connect • Patch panel • Mux/demux • Protection L1

  10. Service Forwarding Control • Best effort IP connectionless • Hop-by-hop IP connectionless • IP Routing (OSFP) • MPLS LDP • MPLS TE L3 • ATM UNI connection oriented • Label switching L2 • call control • Fixed b/w transparent bit service • Electrical cross connect • Optical cross connect • Patch panel • Mux/demux • Protection L1 Motivation - L2/L3 Unified Control • MPLS and IP control subsumes L2 control in order to leverage L2 forwarding advantages.

  11. Service Forwarding Control IP FECs • Best effort IP connectionless • Hop-by-hop IP connectionless • IP Routing (OSFP/ISIS) • MPLS LDP for L1/2 “labels” • MPLS TE L3 L3 API ATMCall control • ATM UNI connection oriented • Label switching L2 L2 API • Fixed b/w transparent bit service • Electrical cross connect • Optical cross connect • SONET Path set up •  Path set up L1 L1 API Unified Control plane • IP Routing and MPLS now used across all layers • Applications can use MPLS LDP APIs to provide different services. • Assumes cross connects can be controlled by signaling.

  12. Extensions to OSPF/IS-IS for Optical Routing 1. Link type (mandatory) 2. Link ID (mandatory) 3. Local interface IP address (mandatory) 4. Remote interface IP address (mandatory) 5. Traffic engineering metric (mandatory) 6. Available Link resource (mandatory) 7. Resource class/Color (mandatory)

  13. Link Type There are two types of links: • service-transparent (ST) link is a link providing transparent bit transmission, • service-aware (SA) link is a link in which interfaces on both ends will handle the payload according to protocol format and/or data bit rate before transmitting and afterreceiving

  14. Type = 6 Length Encoding Type Number of Lambda Bandwidth Number of Lambda Encoding Type Bandwidth 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Available Link resource TLV Encoding Type Description 1 reserved 2 Transparent 3 GE 4 10 GE 5 OC-3/STM-1 6 OC-3c 7 OC-12/STM-4 8 OC-12c 9 OC-48/STM-16 10 OC-48c 11 OC-192/STM-64 12 OC-192c 13 OC-768/STM-256 14 OC-768c “Pools of Lambda”

  15. 100 % 100 % Link Bandwidth is prioritized Lambda Pools Optical Trail LSP Link (Might be Fiber) LSPs @ Priority LSPs Optical Trail LSP Service Transparent (Opaque) Link 0 % 0 % 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 IP Link Layer Over subscription occurs here Set of all Lambda Pools (Might be Fiber Bundle) Pools of Bandwidth - Fit with Existing Model

  16. IS-IS TE-Extensions OSPF TE-Extensions Constraint-Based Routing Functions TE Policy Manager CR-LDP RSVP-TE Path Selection Bandwidth Manager TE Database

  17. IETF Activity IP over Optical Networks - A Framework draft-ip-optical-framework-00.txt MPLS control plane for Switched Optical Networks draft-krishnaswamy-mpls-son-00.txt Extensions to CR-LDP and RSVP-TE for Optical Path Set-up draft-fan-mpls-lambda-signaling-00.txt Extensions to OSPF/IS-IS for Optical Routing draft-wang-ospf-isis-lambda-te-routing-00.txt

  18. Next Steps • We were not the only ones who had drafts on this... • Many of the authors have agreed to merge the drafts into four drafts: • Framework • Signaling • Routing • Link Management Protocol • Routing should go in OSPF and IS-IS WGs • Signaling and LMP are being added to the MPLS Charter • Framework in IPO ?

More Related