1. 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

2. 1 Fedyk & Ghanwani - 1 IETF 47 March 29 2000 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. 2 Fedyk & Ghanwani - 2 IETF 47 March 29 2000 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. 3 Fedyk & Ghanwani - 3 IETF 47 March 29 2000 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. 4 Fedyk & Ghanwani - 4 IETF 47 March 29 2000 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. 5 Fedyk & Ghanwani - 5 IETF 47 March 29 2000 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. 7 Fedyk & Ghanwani - 7 IETF 47 March 29 2000 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. 8 Fedyk & Ghanwani - 8 IETF 47 March 29 2000 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

10. 9 Fedyk & Ghanwani - 9 IETF 47 March 29 2000 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

11. 10 Fedyk & Ghanwani - 10 IETF 47 March 29 2000 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

12. 11 Fedyk & Ghanwani - 11 IETF 47 March 29 2000 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. 12 Fedyk & Ghanwani - 12 IETF 47 March 29 2000 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

14. 13 Fedyk & Ghanwani - 13 IETF 47 March 29 2000 Available Link resource TLV 01234567890123456789012345678901 123 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-16 10 OC-48c 11 OC-192/STM-64 12 OC-192c 13 OC-768/STM-256 14 OC-768c “Pools of Lambda”

15. 14 Fedyk & Ghanwani - 14 IETF 47 March 29 2000 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 % 01234567 Link Link Bandwidth is prioritized LSPs @ Priority IP Link Layer Over subscription occurs here 100 % 0 % 01234567 (Might be Fiber) Lambda Pools

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

17. 16 Fedyk & Ghanwani - 16 IETF 47 March 29 2000 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

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