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

1 Fedyk & Ghanwani - 1 IETF 47 March 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

2 Fedyk & Ghanwani - 2 IETF 47 March 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

3 Fedyk & Ghanwani - 3 IETF 47 March 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)

4 Fedyk & Ghanwani - 4 IETF 47 March 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

5 Fedyk & Ghanwani - 5 IETF 47 March 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?

Extensions to OSPF/IS-IS for Optical Routing

7 Fedyk & Ghanwani - 7 IETF 47 March 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)

8 Fedyk & Ghanwani - 8 IETF 47 March 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 ATM UNI connection oriented Forwarding Label switching Control PNNI, PVC call control Best effort IP connectionless Hop-by-hop IP connectionless IP Routing (OSFP) ARP Fixed b/w transparent bit service Electrical cross connect Optical cross connect Patch panel Mux/demux Protection L1 L2 L3

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

10 Fedyk & Ghanwani - 10 IETF 47 March 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. Service ATM UNI connection oriented Forwarding Label switching Control Best effort IP connectionless Hop-by-hop IP connectionless IP Routing (OSFP/ISIS) MPLS LDP for L1/2 “labels” MPLS TE Fixed b/w transparent bit service Electrical cross connect Optical cross connect L1 L2 L3 L1 API L2 API ATMC all control SONET Path set up Path set up L3 API IP FECs

11 Fedyk & Ghanwani - 11 IETF 47 March 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)

12 Fedyk & Ghanwani - 12 IETF 47 March 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 after receiving

13 Fedyk & Ghanwani - 13 IETF 47 March Available Link resource TLV Encoding Type Type = 6 Length Bandwidth Encoding Type Number of Lambda Bandwidth 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 OC-48c 11 OC-192/STM OC-192c 13 OC-768/STM OC-768c “Pools of Lambda”

14 Fedyk & Ghanwani - 14 IETF 47 March Set of all Lambda Pools (Might be Fiber Bundle) Pools of Bandwidth - Fit with Existing Model Service Transparent (Opaque) Optical Trail LSP Link Optical Trail LSP LSPs 100 % 0 % Link Link Bandwidth is prioritized Priority IP Link Layer Over subscription occurs here 100 % 0 % (Might be Fiber) Lambda Pools

15 Fedyk & Ghanwani - 15 IETF 47 March Constraint-Based Routing Functions Path Selection IS-IS TE-Extensions OSPF TE-Extensions CR-LDP TE Database Bandwidth Manager TE Policy Manager RSVP-TE

16 Fedyk & Ghanwani - 16 IETF 47 March 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 IETF Activity

17 Fedyk & Ghanwani - 17 IETF 47 March 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 ?