1. 1/25/20051 CO internetworking (intra-domain + inter-layer) work in progress Malathi Veeraraghavan, Xuan Zheng, Zhanxiang Huang {mv5g, xuan, zh4c}@virginia.edu Jan. 25, 2005

2. 1/25/20052 CO internetworking (intra-domain + inter-layer)  Terminology, questions Problem description Take a cue from CL internetworking CO internetworking CHEETAH scenario (simple) –Network-by-network setup –Continued setup CO internetworking: complex scenarios with MPLS, VLANs, SONET, WDM Partial CO segments intermixed with CL segments Research problems, key ideas, conclusions Malathi Veeraraghavan, Zhanxiang Huang, Xuan Zheng {mv5g, zh4c, xuan}@virginia.eduxuan}@virginia.edu Nov. 25, 2004

3. 1/25/20053 Terminology A switch is a node in which all interfaces use the same type of multiplexing A gateway has interfaces that use different types of multiplexing Types of multiplexing Circuit based (position-based) Packet based (CO) Different types of packets  Connection-oriented IP (2205)  VLAN (L2SC)  MPLS (PSC-1) SDM (space) TDM (time) WDM (freq.) Note: there is no “CO Ethernet” multiplexing/switching (FSC) (LSC)(TDM) Network Internetwork

4. 1/25/20054 Legend G H IP Host Gateway (any type) IP switch: CL and CO S SONET switch MPLS switch VLAN switch V M E Ethernet switch (by default: CL)

5. 1/25/20055 Questions Difference between LSP encoding type, switching type and GPID –Switching type: type of multiplexing used on the links of an end-to-end LSP. 3471 states “This field normally is consistent across all links of an LSP.” e.g., TDM, PSC-1 –LSP encoding type: type of data carried on each link of the LSP 3471 says “A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats depending on the resource availability and capacity of the link.” 3471: “The LSP Encoding Type represents the nature of the LSP, and not the nature of the links that the LSP traverses.” MRN document says “LSP Encoding Type (representing the nature of the link that the LSP traverses)” and says on a link terminating at a gateway that can perform PSC, TDM and WDM switching, the LSP encoding is lambda. Vijay confirmed my (and MRN) understanding that LSP encoding is below the switching level (actually all the way below) and GPID is above LSP Examples: MPLS switch with PoS link and GbE link. For the PoS link, LSP encoding should be SONET while switching type: PSC-1 and for the GbE link, LSP encoding should be Ethernet and switching type: PSC-1. Vijay says that MPLS specs don’t allow this sort of LSP to be set up. Both switching and LSP encoding type need to be the same across a “switch” for LSP setup! –GPID: what’s carried on the LSP end-to-end

6. 1/25/20056 Questions Nested vs. contiguous vs. stitched LSPs –Tom: if you don’t treat an LSP as an FA LSP and send it out in IGP, then it may be regarded as a contiguous LSP. If there is label stacking, then it is a nested LSP. Unclear. Plain and hybrid nodes: switch and gateway –Chris: Plain node vs. hybrid node – from mrn document – how does it relate to my “switch” and “gateway?” Plain node can also have multiple interface types (from a mux point of view) but only one mux type is enabled in a plain node at a time unlike in a hybrid node.

7. 1/25/20057 CO internetworking (intra-domain + inter-layer) Terminology, questions  Problem description Take a cue from CL internetworking CO internetworking CHEETAH scenario (simple) –Network-by-network setup –Continued setup CO internetworking: complex scenarios with MPLS, VLANs, SONET, WDM Partial CO segments intermixed with CL segments Research problems, key ideas, conclusions Malathi Veeraraghavan, Zhanxiang Huang, Xuan Zheng {mv5g, zh4c, xuan}@virginia.eduxuan}@virginia.edu Nov. 25, 2004

8. 1/25/20058 Initial problem Simplistic starting point in CHEETAH –“Optical Connectivity Service” – check to see if far end has access to CHEETAH service –Added need to find MAC address of far-end host Simplistic answer: Add “OCS available” TXT resource record to domain name in DNS server. Add MAC address associated with domain name again using TXT resource record See example in following two slides

9. 1/25/20059 A simple scenario: Ethernet-SONET-Ethernet End host 1End host 2 EthernetSONET EthernetSONET cloud End host 1 needs to know: IP address of End host 2 to set up Ethernet-over-SONET circuit MAC address of End host 2 to encapsulate Ethernet frames

10. 1/25/200510 DNS based solution for determining availability of optical connectivity and MAC address Use DNS server to obtain MAC address along with IP address of far-side end host. End host 1End host 2 EthernetSONET EthernetSONET cloud Local DNS server Local DNS server High-level DNS server DNS hierarchy architecture End host 2 registers itself in local DNS server with “OCS available” and its MAC address in TXT type Resource Record (RR) End host 1 finds End host 2’s IP address (using query type A) and OCS availability and MAC address (using query type TXT) If local DNS does not have the record for end host 2, it will obtain it through the DNS hierarchy

11. 1/25/200511 Why this approach to obtain MAC address? Avoid ARP broadcast going long-distance! ARP is a fine address resolution scheme if kept local –For performance reasons, let’s not add another “50ms” prop. delay just for ARP –Probably more important: avoid broadcast storms at Ethernet switches in both LANs DNS: natural solution for this mapping; it is already an “address resolution” server translating domain names to IP addresses. Using the DNS infrastructure to obtain MAC addresses (wide area) seems a natural extension. Implementation: –RSVP-TE client at end host 1 writes an entry in the IP routing table (route add) at end host 1 showing that to reach end host 2’s second NIC IP address, next hop is the same IP address. This removes need to place remote end hosts in same subnet –RSVP-TE client at end host 1 writes an entry in the ARP table mapping end host 2’s second NIC IP address to obtained MAC address –Comparable to switch fabric configuration actions at a switch –When an IP datagram is handed to the IP module of end host 1, it sees the destination-specific routing entry in its table and checks ARP table. It finds the MAC address and can encapsulate the IP frame with Ethernet frame and send out without requiring an ARP.

12. 1/25/200512 Initial problem description Three problems with above simplistic solution: –Can have CHEETAH-style network islands that are not interconnected. Even if DNS query confirms “OCS available” for an end host it may not be on the same CHEETAH network as the querying host –Internetwork scenarios: the MAC address to be returned could be that of a gateway, not the far-end host –Partial CO internetworking impacts both “OCS available” and MAC issue.

13. 1/25/200513 A more complex scenario: heterogeneous internetworking End host 1End host 2 Ethernet Switch Ethernet Switch Ethernet Switch Ethernet Switch MPLS router 1MPLS router 2 VLAN 1 VLAN 2 L3 MPLS tunnel In this case, End host 1 needs to know: MAC address of the Ethernet interface 1 on router 1 This should be the destination MAC address in the frames sent by End host 1 1 2

14. 1/25/200514 More complete problem (in context; rather than deconstructed) Answer four phases for operation of heterogeneous CO networks –how should topology/reachability/loading conditions be advertised through routing protocols? –how should paths be pre-computed? –what signaling parameters and values should be used in call setup (Path and Resv messages) –what are the user-plane packet formats?

15. 1/25/200515 CO internetworking Terminology, questions Problem description  Take a cue from CL internetworking CO internetworking CHEETAH scenario (simple) –Network-by-network setup –Continued setup CO internetworking: complex scenarios with MPLS, VLANs, SONET, WDM Partial CO segments intermixed with CL segments Research problems, key ideas, conclusions

16. 1/25/200516 Connectionless Ethernet-IP-Ethernet Scenario ARP MAC ARP MAC End-host A’s IP routing table Host AHost B Gateway I Gateway II Router A’s routing tableRouter B’s routing table B Directly connected BIP address of gateway I.1 interface BSwitch 3.1 interface End-host A’s Internet to network address mapping table (ARP table) I.1 interface IP addr.I.1 interface MAC addr. Internet addressNetwork 1 address READ NOTES G G Ethernet packet-based multiplexing on all links Switch 1 (Ethernet) Switch 2 (Ethernet) Network 1 EE H H I.1 Switch 3 (IP) IP multiplexing on all links (e.g. all PPP links) Network 2 I.2II.23.13.2 IP II.3 Ethernet packet-based multiplexing on all links Network 3 Switch 4 (Ethernet) Switch 5 (Ethernet) E E

17. 1/25/200517 CO internetworking Terminology, questions Problem description Take a cue from CL internetworking  CO internetworking CHEETAH scenario –Network-by-network setup –Continued setup CO internetworking: scenarios with MPLS, VLANs, SONET, WDM Partial CO segments intermixed with CL segments Research problems, key ideas, conclusions

18. 1/25/200518 Cheetah Scenario: Dedicated Ethernet-SONET-Dedicated Ethernet (actually SDM-TDM-SDM) Routing info distribution phases GW1 GW2 H1 H2 I.1 II.3I.2II.23.13.2 G HH G VLSR S Network 1 TDM muxing Internetwork: SDM muxing based network GW1’s link state database RouterLinkSw. Cap. GW2SW1:3.2-II.2TDM GW2II.3FSC SW1 (SONET) LSA originated by GW2 LinkTypeSw. Cap. II.33FSC SW1:3.2-II.22TDM LSA originated by SW1 LinkTypeSw. Cap. GW:I.2-3.12TDM 3.2-GW2:II.22TDM GW2 is a gateway GW1 is a gateway LSA originated by GW2 LinkTypeSw. Cap. GW1-GW2PretendFSC/TDM GW1’s link state database RouterLinkSw. Cap. GW2SW1:3.2-II.2TDM GW2II.3FSC GW2GW1-GW2FSC/TDM

19. 1/25/200519 Cheetah Scenario: Dedicated Ethernet-SONET-Dedicated Ethernet (actually SDM-TDM-SDM) Path-computation phases GW1’s Link State Database RouterLinkSw. Cap. GW2GW1-GW2FSC/TDM GW2II.3FSC ……… GW1 GW2 H1 H2 I.1 II.3I.2II.23.13.2 G HH G VLSR S Network 1 TDM muxing Internetwork: SDM muxing based network SW1 (SONET) DestNext hopCO type H2GW2SDM DestNext hopCO type GW2SW1TDM Inner routing table Outer routing table CSPF

20. 1/25/200520 Cheetah Scenario: Dedicated Ethernet-SONET-Dedicated Ethernet (actually SDM-TDM-SDM) Signaling phase (network-by-network setup: nested LSPs) GW1GW2 PATH H1 H2 RESV I.1 II.3I.2II.23.13.2 G HH G READ NOTES VLSR S Network 1 TDM muxing Internetwork: SDM muxing based network PathDestBWSw. cap.LSP enc.GPID H1-GW1-GW2-H2H2Intserv TspecFSCFiber or Ethernet?Ethertype GW1-SW1-GW2GW2SONET TspecTDMSONET/SDH ResvStack of labels H2-GW2-GW1-H1H2 MAC (know to generate this because of GPID) GW1-SW1-GW2GW2 MAC End-host A’s CO IP routing table (consulted by RSVP- TE client) H2GW1 SW1 (SONET)

21. 1/25/200521 Cheetah Scenario: Dedicated Ethernet-SONET-Dedicated Ethernet (actually SDM-TDM-SDM) User-plane: Data-flow phase H1 H2 I.1 II.3I.2II.23.13.2 G HH G VLSR S Network 1 TDM muxing Internetwork: SDM muxing based network H2 MAC H2 IP Data H2 MAC H2 IP Data SONET frame H2 MAC H2 IP Data End-host A’s CO IP routing table (consulted by RSVP- TE client) H2GW1 GW2 SW1 (SONET)

22. 1/25/200522 Cheetah Scenario: Dedicated Ethernet-SONET-Dedicated Ethernet (actually SDM-TDM-SDM) (continued setup: also a nested LSP!) PATH H1H2 RESV I.1 II.3I.2II.23.13.2 Network 1 Doesn’t seem to be a good solution; mismatches in crossconnect rates (e.g., lambda); gets complex if VCAT necessitates multiple LSPs G HH G S READ NOTES VLSR Internetwork: SDM muxing based network GW1GW2 SW1 (SONET) End-host A’s CO IP routing table (consulted by RSVP- TE client) H2GW1

23. 1/25/200523 CO internetworking Terminology, questions Problem description Take a cue from CL internetworking CO internetworking CHEETAH scenario (simple) –Network-by-network setup –Continued setup  CO internetworking: complex scenarios with MPLS, VLANs, SONET, WDM Partial CO segments intermixed with CL segments Research problems, key ideas, conclusions

24. 1/25/200524 Before we start with the scenarios Learn what current gateway implementations actually do Some background on OSPF, OSPF-TE and GMPLS extensions Key idea: Pretend links; allows for homogeneous LSPs to be setup in nested mode Outermost network: SDM, VLAN, IP –Two points

25. 1/25/200525 User-plane capabilities (to support CO internetworking) Three types of gateways: –Summit Extreme SDM ↔ VLAN (untagged ports to tagged VLANs) –Cisco GSRs IP ↔ MPLS VLAN ↔ MPLS SDM ↔ VLAN (port mapped Ethernet over MPLS) –Cisco 15454/Movaz SDM ↔ SONET SDM ↔ WDM VLAN ↔ SONET? (Ethernet cards in 454)? IP ↔ SONET? (ML series cards in 454)?

26. 1/25/200526 User-plane capabilities (to support CO internetworking) Summit Extreme –Can crossconnect SDM to VLAN –Meaning place an untagged port (port mapped) to a VLAN along with a tagged port (with a VLAN ID) –Switch is capable of popping on label (VLAN ID) and popping it off if outgoing port is untagged –The form of mux/demux on each port is changeable on a packet-by-packet basis – quite amazing! on packet can come in w/o a VLAN tag requiring the switch to forward it according to rules of its untagged VLAN setting another packet can come in with a VLAN tag and need to be switched accordingly.

27. 1/25/200527 User-plane capabilities (to support CO internetworking) Cisco GSR –“L3 MPLS” – map packets of a certain flow to an MPLS tunnel. –Ethernet over MPLS VLAN Port mapped VLAN rewrite –This is simply a CO PS scenario where the label is changed. With a VLAN, the same label is used on all links unlike in the more generic CO PS where labels are only unique to a link –With VLAN rewrite on the other side of a different type of network, the VLAN ID is changed (i.e. label).

28. 1/25/200528 User-plane capabilities (to support CO internetworking) Cisco 15454 and Movaz box –Can map all frames arriving on a port to a SONET circuit or wavelength SDM ↔ SONET or WDM Unsure whether Ethernet cards are capable of processing VLAN IDs or IP header fields to then decide which ones to map to a certain SONET circuit or wavelength

29. 1/25/200529 Background (what info does a switch/gateway have) OSPF (2328): –Summary LSAs, Router LSAs, Network LSAs –Summary LSAs sent by area border routers with reachability information OSPF-TE (3630): –TE LSAs – top-level TLV: Link TLV ccamp extensions for GMPLS: –sub-TLVs that describe switching capability on link identified in top-level Link TLV

30. 1/25/200530 OSPF-TE (3630) The following sub-TLVs of the Link TLV are defined: 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4 octets) 4 - Remote interface IP address (4 octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets)

31. 1/25/200531 ccamp extensions for GMPLS Sub-TLV Type Length Name 11 8 Link Local/Remote Identifiers 14 4 Link Protection Type 15 variable Interface Switching Capability Descriptor 16 variable Shared Risk Link Group

32. 1/25/200532 GSR capabilities and Link TLVs Cisco GSR is capable of –“L3 MPLS” – mapping a flow at the IP layer to an MPLS LSP –Ethernet over MPLS: VLAN Port mapped VLAN rewrite – this is nothing but changing labels –generically in CO PS networks the labels are unique only to each link; which means they are mapped from link to link on the end-to-end path.

33. 1/25/200533 GSR capabilities and Link TLVs These capabilities of the GSRs got us wondering whether in addition to Link TLVs in TE LSAs we need some way of identifying the capabilities of the gateways –e.g., whether it supports VLAN over MPLS in addition to L3 MPLS One answer: –Don’t need another TLV –The gateways need to “pretend” they are interconnected by logical links and advertise the switching capability (i.e., the types of multiplexing) available on these links –If two LERs at the edge of an MPLS cloud can support VLAN over MPLS then they advertise a direct logical link between the LERs, which supports VLAN multiplexing

34. 1/25/200534 Use routing data to ask for the right type of connection By spreading multiplexing capabilities on these “pretend” logical links, a gateway/switch can determine whether or not there is an end-to-end path with a certain type of multiplexing If the routing data is somehow wrong, a gateway/switch should simply reject a call if it receives a Path request for a certain type of connection that it does not support (e.g., a request for a TDM circuit via a WDM switch or a request for a VLAN connection to a gateway whose outgoing logical links to other gateways on an MPLS cloud do not support “VLAN over MPLS”

35. 1/25/200535 Possible multiplexing schemes on the CO internetwork, i.e., the outermost network Three possibilities –SDM (Fiber switch capable) –VLAN –IP (Connection-oriented)

36. 1/25/200536 Two points re. outermost network Presence of IP and Ethernet even with SDM outermost network Forget hierarchy

37. 1/25/200537 Point 1: Presence of IP and Ethernet even with SDM outermost network Even when SDM is outermost network, user-data payload is carried in IP datagrams encapsulated in Ethernet frames –Reason 1: Use socket API in application programming – which means IP datagram encapsulation is a given. –Reason 2: Ethernet is the common NIC for end hosts; so Ethernet frame encapsulation is a given. Small overhead – hence ignored

38. 1/25/200538 Point 2: Forget hierarchy Conventional thinking: –SDM is at the lowest level of the hierarchy –Common view: MPLS over SONET over WDM over fiber Contrary view here: –SDM (aka) fiber is outermost network! Any “multiplexing/switching layer” can ride on top of any other multiplexing/switching layer –Just depends on network topology

39. 1/25/200539 Scenarios Scenario 1: SDM-(VLAN)-(MPLS)-(VLAN)- SDM –No VLAN capability at end host NICs; but these NICs are connected to Ethernet switches with VLAN cap. –Gateways between VLAN and MPLS networks have VLAN capability in Ethernet cards but these gateways have no support to carry VLAN frames on MPLS LSPs Gateways issue OSPF-TE LSAs indicating GW↔GW “pretend” links support FSC Also basic OSPF LSAs indicate availability of “pretend” links allowing for CO IP to the outermost network (internetwork) –Make outermost network call setup be SDM

40. 1/25/200540 End-to-end CO: Scenario 1 SDM-(VLAN)-(MPLS)-(VLAN)-SDM Routing info distribution phases VLAN multiplexing H1 H2 G M H VG H VG G VLSR Network 1Network 2Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 GW2’s LSA LinkTypeSw. Cap. SW1-GW22L2SC GW2-SW22PSC-1 GW1’s LSA LinkTypeSw. Cap. GW1-SW12L2SC GW1-H13FSC SW1’s LSA LinkTypeSw. Cap. GW1-SW12L2SC SW1-GW22L2SC GW1’s Link State Database RouterLinkSw. Cap. GW2SW1:3.2-II.2TDM GW2II.3FSC GW2 is a gateway GW1 and GW3 are gateway s GW2 and GW4 are gateway s GW3 is a gateway GW1’s Link State Database RouterLinkSw. Cap. GW2GW1-GW2FSC/L2SC GW2GW2-GW3FSC/PSC-1 GW3GW3-GW4FSC/L2SC GW2’s LSA LinkLink typeSw. Cap. SW1-GW22L2SC GW2-SW22PSC-1 GW1-GW2PretendFSC/L2SC GW2-GW3PretendFSC/PSC-1

41. 1/25/200541 End-to-end CO: Scenario 1 SDM-(VLAN)-(MPLS)-(VLAN)-SDM Routing path precomputation phases GW1’s LS database RouterLinkLink typeSw. Cap. GW2GW1-SW12L2SC GW2GW2-SW22PSC-1 GW2GW2-GW3PretendFSC GW2GW1-GW2PretendFSC ………… VLAN multiplexing H1 H2 G M H VG H VG G VLSR Network 1Network 2Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 Internetwork: SDM muxing based network Dest.Next hopSw. Cap. H2GW2FSC Dest.Next hopSw. Cap. GW2SW1L2SC CSPF Outer Routing table Inner Routing table

42. 1/25/200542 End-to-end CO: Scenario 1 SDM-(VLAN)-(MPLS)-(VLAN)-SDM Signaling phase VLAN multiplexing PATH RESV H1 H2 G M H VG H VG G VLSR Network 1Network 2Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 PathDestBWSw. cap.LSP enc.GPID H1-GW1-GW2-GW3-GW4-H2H2Intserv TspecFSC Fiber or Ethernet? Ethertype GW1-SW1-GW2GW2Intserv TspecL2SC Ethernet or packet? VLAN? Ethertype GW2-SW2-GW3GW3Intserv TspecPSC-1 Packet? Ethernet? Ethertype GW3-SW3-GW4GW4Intserv TspecL2SC Ethernet or packet? VLAN? Ethertype ResvStack of labels H1-GW1-GW2-GW3-GW4-H2H2 MAC (know to generate this because of GPID) GW1-SW1-GW2GW2 MAC + VLAN ID GW2-SW2-GW3 (assuming Eth. links)GW3 MAC + MPLS label GW3-SW3-GW4GW4 MAC + VLAN ID Internetwork: SDM muxing based network

43. 1/25/200543 End-to-end CO: Scenario 1 SDM-(VLAN)-(MPLS)-(VLAN)-SDM User-plane: data flow phase (MPLS network links are both Ethernet) VLAN multiplexing H1 H2 G M H VG H V GG VLSR Network 1Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 H2 MAC H2 IP Data H2 MAC H2 IP Data Network 2 Internetwork: SDM muxing based network H2 MAC H2 IP Data VLAN 1 ID GW2 MAC H2 MAC H2 IP Data MPLS Label GW3 MAC H2 MAC H2 IP Data VLAN 1 ID GW4 MAC

44. 1/25/200544 End-to-end CO: Scenario 1 SDM-(VLAN)-(MPLS)-(VLAN)-SDM User-plane: data flow phase (MPLS network links are both PPP) VLAN multiplexing H1 H2 G M H VG H V GG VLSR Network 1Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 H2 MAC H2 IP Data H2 MAC H2 IP Data Network 2 Internetwork: SDM muxing based network H2 MAC H2 IP Data VLAN 1 ID GW2 MAC H2 MAC H2 IP Data MPLS Label PPP header H2 MAC H2 IP Data VLAN 1 ID GW4 MAC

45. 1/25/200545 End-to-end CO: Scenario 1 SDM-(VLAN)-(MPLS)-(VLAN)-SDM Signaling phase MPLS network: first link is PPP and the second Ethernet PathDestBWSw. cap.LSP enc.GPID H1-GW1-GW2-GW3-GW4-H2H2Intserv TspecFSC Fiber or Ethernet? Ethertype GW1-SW1-GW2GW2Intserv TspecL2SC Ethernet or packet? VLAN? Ethertype GW2-SW2-GW3GW3Intserv TspecPSC-1 Packet? Ethernet? Ethertype GW3-SW3-GW4GW4Intserv TspecL2SC Ethernet or packet? VLAN? Ethertype ResvStack of labels H1-GW1-GW2-GW3-GW4-H2H2 MAC (know to generate this because of GPID) GW1-SW1-GW2GW2 MAC + VLAN ID GW2-SW2-GW3 (assuming Eth. links)GW3 MAC + MPLS label GW3-SW3-GW4GW4 MAC + VLAN ID VLAN multiplexing PATH RESV H1 H2 G M H VG H VG G VLSR Network 1Network 2Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 Internetwork: SDM muxing based network

46. 1/25/200546 Scenarios contd. Scenario 2: SDM-(VLAN-(MPLS)-VLAN)-SDM –No VLAN capability at end host NICs; but these NICs are connected to Ethernet switches with VLAN cap. –Gateways between VLAN and MPLS networks have VLAN capability in Ethernet cards and these gateways have support to carry VLAN frames on MPLS LSPs Gateways issue OSPF-TE LSAs indicating GW↔GW “pretend” links support FSC and L2SC (VLAN) Also basic OSPF LSAs indicate availability of “pretend” links allowing for CO IP to the outermost network (internetwork) –Make outermost network call setup be SDM

47. 1/25/200547 End-to-end CO: Scenario 2 SDM-(VLAN-(MPLS)-VLAN)-SDM Routing info distribution phases VLAN multiplexing H1 H2 G M H VG H VG G VLSR Network 1Network 2Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 Internetwork: SDM muxing based network GW1’s LSA LinkTypeSw. Cap. GW1:H13FSC GW1-SW12L2SC SW1’s LSA LinkTypeSw. Cap. GW1-SW12L2SC SW1-GW22L2SC LinkTypeSw. Cap. SW1-GW22L2SC GW2-SW22PSC-1/L2SC GW1’s Link State Database RouterLinkSw. Cap. GW2SW1-GW2L2SC GW2GW2-SW2PSC-1 ……… GW2 is a gateway GW1 and GW3 are gateway s GW2 and GW4 are gateway s GW3 is a gateway GW2’s LSA LinkTypeSw. Cap. GW1-GW2PretendFSC/L2SC GW2-GW3PretendFSC/PSC-1/L2SC GW1’s Link State Database RouterLinkSw. Cap. GW4GW1-GW4FSC/L2SC GW4GW4:H2FSC ………

48. 1/25/200548 End-to-end CO: Scenario 2 SDM-(VLAN-(MPLS)-VLAN)-SDM Routing path precomputation phases VLAN multiplexing H1 H2 G M H VG H VG G VLSR Network 1Network 2Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 Internetwork: SDM muxing based network GW1’s Link State Database RouterLinkSw. Cap. GW4GW1-GW4FSC/L2SC GW4GW4:H2FSC GW2GW2-GW3FSC/L2SC/PSC-1 ……… Dest.Next hopSw. Cap. H2GW4FSC CSPF Outer Routing tables Dest.Next hopSw. Cap. GW4GW2L2SC Inner Dest.Next hopSw. Cap. GW2SW1L2SC Intermediate

49. 1/25/200549 End-to-end CO: Scenario 2 SDM-(VLAN-(MPLS)-VLAN)-SDM Signaling phase (MPLS network links are both Ethernet) VLAN multiplexing PATH RESV H1 H2 G M H VG H VG G VLSR Network 1Network 2Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 PathDestBWSw. capsLSP enc.GPID H1-GW1-GW4-H2H2Intserv TspecFSCFiberEthertype GW1-SW1-GW2-GW3-SW3-GW4GW4?L2SC?Ethertype GW2-SW2-GW3GW3Intserv TspecPSC-1PacketEthertype Internetwork: SDM muxing based network ResvStack of labels H1-GW1-GW4-H2H2 MAC (know to generate this because of GPID) GW1-SW1-GW2-GW3-SW3-GW4GW2 MAC + VLAN ID GW2-SW2-GW3GW3 MAC + VLAN ID +MPLS label

50. 1/25/200550 End-to-end CO: Scenario 2 SDM-(VLAN-(MPLS)-VLAN)-SDM User-plane: data flow phase (MPLS network links are both Ethernet) VLAN multiplexing H1 H2 G M H VG H VG G VLSR Network 1 Network 3 GW1 MPLS multiplexing SW1 GW4 GW3GW2SW2 SW3 H2 MAC H2 IP Data H2 MAC H2 IP Data Network 2 H2 MAC H2 IP Data VLAN 1 ID GW2 MAC H2 MAC H2 IP Data MPLS Label VLAN 1 ID GW3 MAC H2 MAC H2 IP Data VLAN 1 ID GW4 MAC Internetwork: SDM muxing based network

51. 1/25/200551 Scenarios contd. Scenario 3: VLAN-(MPLS)-VLAN –VLAN capability at end host NICs and these NICs are connected to Ethernet switches with VLAN cap. –Gateways between VLAN and MPLS networks have VLAN capability in Ethernet cards and these gateways have support to carry VLAN frames on MPLS LSPs Gateways issue OSPF-TE LSAs indicating GW↔GW “pretend” links support FSC and L2SC (VLAN) Also basic OSPF LSAs indicate availability of “pretend” links allowing for CO IP to the outermost network (internetwork) –Make outermost network call setup be VLAN

52. 1/25/200552 End-to-end CO: Scenario 3 VLAN-(MPLS)-VLAN Routing info distribution phases VLAN multiplexing H1 H2 G M H VV H VV G VLSR Network 2 SW1 MPLS multiplexing SW2 SW5 GW3GW2SW3 SW4 GW2’s LSA LinkTypeSw. Cap. GW2-SW32PSC-1 SW2-GW22L2SC GW2’s LSA LinkTypeSw. Cap. GW2-SW32PSC-1 SW3-GW32PSC-1 GW2’s LSA LinkTypeSw. Cap. SW3-GW32PSC-1 GW3-SW42L2SC GW2’s Link State Database RouterLinkSw. Cap. GW3SW3-GW3PSC-1 GW3GW3-SW4L2SC ……… GW3 is a gateway GW2 is a gateway GW2’s LSA LinkTypeSw. Cap. SW3-GW32PSC-1 GW3-SW42L2SC GW2-GW3PretendL2SC GW2’s Link State Database RouterLinkSw. Cap. GW3GW2-GW3FSC/L2SC/PSC-1 GW3GW3-SW4L2SC ………

53. 1/25/200553 End-to-end CO: Scenario 3 VLAN-(MPLS)-VLAN Routing path precomputation phases VLAN multiplexing H1 H2 G M H VV H V G VLSR Network 2 SW1 MPLS multiplexing SW2 GW3GW2SW3 SW4 V SW5 GW2’s Link State Database RouterLinkSw. Cap. GW3GW2-GW3FSC/L2SC/PSC-1 GW3GW3-SW4L2SC ……… Dest.Next hopSw. Cap. H2GW3FSC CSPF Outer Routing tables Inner Dest.Next hopSw. Cap. GW3SW3PSC-1

54. 1/25/200554 End-to-end CO: Scenario 3 VLAN-(MPLS)-VLAN Signaling phase (MPLS network links are both Ethernet) VLAN multiplexing PATH RESV H1 H2 G M H VV H V G VLSR Network 2 SW1 MPLS multiplexing SW2 GW3GW2SW3 SW4 PathDestBWSw. capsLSP enc.GPID H1-SW1-SW2-GW2-GW3- SW4-GW4-H2 H2?L2SC?Ethertype GW2-SW3-GW3GW3Intserv TspecPSC-1PacketEthertype ResvStack of labels H1-SW1-SW2-GW2-GW3-SW4-GW4- H2 H2 MAC (know to generate this because of GPID) GW2-SW3-GW3GW3 MAC + VLAN ID V SW5

55. 1/25/200555 End-to-end CO: Scenario 3 VLAN-(MPLS)-VLAN Signaling phase (MPLS network links are both Ethernet) VLAN multiplexing H1 H2 G M H VV H V G VLSR Network 2 SW1 MPLS multiplexing SW2 GW3GW2SW3 SW4 H2 MAC H2 IP Data VLAN 1 ID GW2 MAC H2 MAC H2 IP Data MPLS Label VLAN 1 ID GW3 MAC H2 MAC H2 IP Data VLAN 1 ID H2 MAC V SW5

56. 1/25/200556 Scenarios contd. Scenario 4: VLAN-(SONET)-VLAN –VLAN capability at end host NICs and these NICs are connected to Ethernet switches with VLAN cap. –Gateways between VLAN and SONET networks have VLAN capability in Ethernet cards and these gateways have support to carry VLAN frames on SONET circuits Gateways issue OSPF-TE LSAs indicating GW↔GW “pretend” links support FSC and L2SC (VLAN) Also basic OSPF LSAs indicate availability of “pretend” links allowing for CO IP to the outermost network (internetwork) –Make outermost network call setup be VLAN –See notes

57. 1/25/200557 End-to-end CO: Scenario 4 VLAN-(SONET)-VLAN Routing info distribution phases VLAN multiplexing H1 H2 G M H VV H VV G VLSR Network 2 SW1 SONET multiplexing SW2 SW5 GW3GW2SW3 SW4 GW2’s LSA LinkTypeSw. Cap. GW2-SW32TDM SW2-GW22L2SC GW2’s LSA LinkTypeSw. Cap. GW2-SW32TDM SW3-GW32TDM GW2’s LSA LinkTypeSw. Cap. SW3-GW32TDM GW3-SW42L2SC GW2’s Link State Database RouterLinkSw. Cap. GW3SW3-GW3TDM GW3GW3-SW4L2SC ……… GW3 is a gateway GW2 is a gateway GW2’s LSA LinkTypeSw. Cap. SW3-GW32TDM GW3-SW42L2SC GW2-GW3PretendFSC/TDM GW2’s Link State Database RouterLinkSw. Cap. GW3GW2-GW3FSC/TDM GW3GW3-SW4L2SC ………

58. 1/25/200558 End-to-end CO: Scenario 4 VLAN-(SONET)-VLAN Routing protocol and path precomputation phases VLAN multiplexing H1 H2 G M H VV H V G VLSR Network 2 SW1 SONET multiplexing SW2 GW3GW2SW3 SW4 V SW5 GW2’s Link State Database RouterLinkSw. Cap. GW3GW2-GW3FSC/TDM GW3GW3-SW4L2SC ……… Dest.Next hopSw. Cap. H2GW3FSC CSPF Outer Routing tables Inner Dest.Next hopSw. Cap. GW3SW3TDM

59. 1/25/200559 End-to-end CO: Scenario 4 VLAN-(SONET)-VLAN Signaling phase PATH RESV H1 H2 G S H VV H V G VLSR Network 2 SW1 SONET multiplexing SW2 GW3GW2SW3 SW4 PathDestBWSw. capsLSP enc.GPID H1-SW1-SW2-GW2- GW3-SW4-GW4-H2 H2?L2SC?Ethertype GW2-SW3-GW3GW3SONET TspecTDMSONET/SDH ResvStack of labels H1-SW1-SW2-GW2-GW3-SW4- GW4-H2 H2 MAC (know to generate this because of GPID) GW2-SW3-GW3GW3 SONET label + VLAN ID VLAN multiplexing V SW5

60. 1/25/200560 End-to-end CO: Scenario 4 VLAN-(SONET)-VLAN User-plane: data flow phase VLAN multiplexing H1 H2 G S H VV H V G VLSR Network 2 SW1 SONET multiplexing SW2 GW3GW2SW3 SW4 H2 MAC H2 IP Data SONET frame VLAN 1 ID H2 MAC H2 IP Data VLAN 1 ID GW2 MAC H2 MAC H2 IP Data VLAN 1 ID H2 MAC V SW5

61. 1/25/200561 For each scenario, answer the following questions 1.Routing protocol and path pre-computation phase: What should have been advertised by OSPF-TE and what computations should have been run by CSPF modules? 2.Signaling phase: What types of objects are used in Path messages for the five parameters and what values are set in the key fields of these objects? What labels are carried in the Resv messages? Which interface’s MAC address is necessary at sender? 3.User-plane: Packet formats on each interface

62. 1/25/200562 Why end host needs CO reachability information with type of CO service (slide i) In CL IP networks: –default setting: use IP subnet address to determine whether destination is directly reachable or not? –this allows sending end host to issue an ARP with IP address of destination host or IP address of gateway (typically just one – since there is only one type of internetwork CL service, aka IP)

63. 1/25/200563 Why end host needs CO reachability information with type of CO service (slide ii) If the sending host has a manually set entry in its IP routing table for the destination host which is on a different subnet as well as an entry in the ARP table giving the MAC address of the destination (H2) –It can generate a frame with destination MAC address = H2 and destination IP address = H2 –The default gateway will not intercept the packet in some sort of proxy mode and relay it to the destination –This is an application of the “end-to-end argument” –If the gateway did intercept such a packet, it becomes more like Intelligent Networks –What will happen is that the default gateway will not accept the packet since the destination MAC address does not match it’s own interface’s MAC address. Therefore the packet will just be dropped

64. 1/25/200564 Why end host needs CO reachability information with type of CO service (slide iii) Applying similar reasoning –it is the responsibility of the end host to generate a Path message requesting the “right” type of connection to a destination, i.e., one that is indeed available. –if such a connection is not possible, the call should be rejected Sending end host has three options for the type of connection it can request –SDM –VLAN –CO IP

65. 1/25/200565 Why end host needs CO reachability information with type of CO service (slide iv) This concept of the gateway not automatically changing the type of Path request holds at each hop. Example: –In scenario 1, if the VLAN-MPLS GW2 had not announced availability of SDM multiplexing on its pretend link to the far-end GW on the MPLS network, the SDM-VLAN GW1 would not have issued the Path request of the SDM variety. –By having OSPF-TE LSAs for pretend links, we can use the end- to-end argument in CO networks –Without these LSAs, gateways would need to automatically convert the type of requests – makes it more IN like.

66. 1/25/200566 Why end host needs CO reachability information with type of CO service (slide v) Implication –End hosts need to keep a CO routing table –How is this information learned at end hosts –LMP? Since end hosts don’t run OSPF Destination IP addr (subnet or host) Gateway (next-hop) Type of connection (SDM, VLAN, CO IP)

67. 1/25/200567 CO internetworking Terminology, questions Problem description Take a cue from CL internetworking CO internetworking CHEETAH scenario (simple) –Network-by-network setup –Continued setup CO internetworking: complex scenarios with MPLS, VLANs, SONET, WDM  Partial CO segments intermixed with CL segments Research problems, key ideas, conclusions

68. 1/25/200568 Partial Connection Oriented: Scenario 1 Ethernet-MPLS-Ethernet Scenario Routing protocol and path precomputation phases Ethernet packet-based multiplexing (E1) Ethernet packet-based multiplexing (E2) GW1 GW2 End-host A’s routing table H1 H2 Network 1 Network 2 Network 3 I.1 I.2II.2 II.3 3.13.2 SW3 (MPLS) E G M H EEE H G VLSR IP packet-based multiplexing H2GW1 LinkSw. Cap. GW1-GW2PSC-1 GW2’s advertised link TLVs LinkSw. Cap. GW1-GW2PSC-1 GW3’s advertised link TLVs

69. 1/25/200569 Partial Connection Oriented: Scenario 1 Ethernet-MPLS-Ethernet Scenario Signaling phase Ethernet packet-based multiplexing (E1) Ethernet packet-based multiplexing (E2) GW1 GW2 PATH H1 H2 tagging untagging RESV Network 1 Network 2 Network 3 I.1 I.2II.2II.33.13.2 SW3 (MPLS) E G M H EEE H G VLSR End-host A’s routing table H2GW1 Ethernet packet-based multiplexing PathDestBWSw. capsLSP enc.GPID H1-SW2-GW2-H2H2Intserv TspecPSC-1PacketEthertype GW1-SW3-GW2GW3Intserv TspecPSC-1PacketEthertype ResvStack of labels H1-GW1-GW2-H2H2 MAC (know to generate this because of GPID) GW2-SW3-GW3GW2 MAC + MPLS label

70. 1/25/200570 Partial Connection Oriented: Scenario 1 Ethernet-MPLS-Ethernet Scenario User-plane: data flow phase (MPLS network links are both Ethernet) Ethernet packet-based multiplexing (E1) Ethernet packet-based multiplexing (E2) GW1 GW2 H1 H2 Network 1 Network 2 Network 3 I.1 I.2II.2II.33.13.2 SW3 (MPLS) E G M H EEE H G VLSR GW1 MAC H2 IP Data H2 MAC H2 IP Data H2 IP Data MPLS Label GW2 MAC

71. 1/25/200571 Partial Connection Oriented: Scenario 2 Ethernet-SONET-Ethernet Scenario Routing protocol and path precomputation phases Ethernet packet-based multiplexing (E1) Ethernet packet-based multiplexing (E2) GW1 GW2 End-host A’s routing table H1 H2 Network 1 Network 2 Network 3 I.1 I.2II.2 II.3 3.13.2 SW3 (SONET) E G M H EEE H G VLSR Ethernet packet-based multiplexing H2GW1 LinkSw. Cap. GW1-GW2TDM GW2’s advertised link TLVs LinkSw. Cap. GW1-GW2TDM GW3’s advertised link TLVs

72. 1/25/200572 Partial Connection Oriented: Scenario 2 Ethernet-SONET-Ethernet Scenario Signaling phase Ethernet packet-based multiplexing (E1) Ethernet packet-based multiplexing (E2) GW1 GW2 PATH H1 H2 tagging untagging RESV Network 1 Network 2 Network 3 I.1 I.2II.2II.33.13.2 SW3 (SONET) E G M H EEE H G VLSR End-host A’s routing table H2GW1 Ethernet packet-based multiplexing PathDestBWSw. capsLSP enc.GPID H1-SW2-GW2-H2H2Intserv TspecPSC-1PacketEthertype GW1-SW3-GW2GW3SONET TspecTDMSONET/SDH ResvStack of labels H1-GW1-GW2-H2H2 MAC (know to generate this because of GPID) GW1-SW3-GW2GW2 SONET label

73. 1/25/200573 Partial Connection Oriented: Scenario 2 Ethernet-SONET-Ethernet Scenario User-plane: data flow phase Ethernet packet-based multiplexing (E1) Ethernet packet-based multiplexing (E2) GW1 GW2 H1 H2 Network 1 Network 2 Network 3 I.1 I.2II.2II.33.13.2 SW3 (MPLS) E G M H EEE H G VLSR GW1 MAC H2 IP Data H2 MAC H2 IP Data H2 IP Data H2 MAC SONET frame

74. 1/25/200574 CO internetworking (intra-domain + inter-layer) Terminology, questions Problem description Take a cue from CL internetworking CO internetworking CHEETAH scenario (simple) –Network-by-network setup –Continued setup CO internetworking: complex scenarios with MPLS, VLANs, SONET, WDM Partial CO segments intermixed with CL segments  Research problems, key ideas, conclusions Malathi Veeraraghavan, Zhanxiang Huang, Xuan Zheng {mv5g, zh4c, xuan}@virginia.eduxuan}@virginia.edu Nov. 25, 2004

75. 1/25/200575 Research vs. eng. problems Problem statement –How to create connections (rate-guaranteed allocations) across CO networks that support different types of multiplexing? Mostly engineering problems –What type of Path message objects to use, and what values to use for the fields in these objects? –How to declare “pretend” links to allow for path computation or next-hop

76. 1/25/200576 “Pretend” links How many pretend links should be advertised to outside this network? –N(N-1)/2 links, where N is number of GWs, e.g.,GW1↔GW2; GW1↔GW3..... What is the capacity for each of these pretend links? How should gateway-to-switch and switch-to-switch link capacity be divided between the pretend links before advertising – estimates? Actual routing of connections to make these pretend links real can be changed during setup. Switching capabilities on these links are easy – if GW1 supports VLAN over MPLS as well as Layer 3 MPLS, just advertise L2SC, SDM and whatever allows for 2205 RSVP (which is CO IP) G M G GG G M M M M GW1 GW3 GW2 GW4 GW5 SW1 SW5 SW4 SW3 SW2 Path OSPF MPLS mux.

77. 1/25/200577 Is there a research problem? First consider the research problems in this whole area of routing/signaling/user-plane protocols – in homogeneous networks –There are two problems when deconstructed (i.e, context is removed) 1.routing problem deconstructs to the constrained shortest path computation in a graph problem 2.signaling – main aspect is bandwidth management – CAC; so here the research problem is how to bandwidth share? Accept/reject a call or provide less BW than asked for? Classes of service; fairness traded off against utilization; ULGM sharing; how to set UL and GMs?

78. 1/25/200578 CSPF routing deconstructed problem in homogeneous network Example constraint: bandwidth Problem: find SP from a-f with min. BW = 30Mbps a c d b e f 2, 30Mbps 5, 100Mbps 1, 150Mbps 1, 10Mbps 1, 50Mbps 1, 500Mbps 2, 50Mbps 1, 50Mbps Link weight Available BW Answer: a-b-c-e-f: path weight = 2 + 5 + 1 + 1 = 9 Path a-b-d-f is shortest path with path weight = 2+1+1 = 4, but BW available is only 10Mbps, less than the required 30Mbps

79. 1/25/200579 How does the addition of the heterogeneity dimension affect these two research problems? Routing problem a c d b e f 2, 30Mbps 1, 3200Gbps 1, 8000Gbps 5, 100Mbps 2, 10Gbps 1, 10Gbps 1, 2.5Gbps Link weight Available BWe.g., WDM switch e.g., SONET switch e.g., MPLS switch Crossconnect granularity 1Mbps 51Mbps 10Gbps New constraint: node crossconnect granularity Problem: find SP from a-f with min. BW = 30Mbps Answer: a-b-d-f: path weight = 2 + 1 + 1 = 4, and 30Mbps is available, but it needs the setup of a 10Gbps circuit on b-d-f before 30Mbps can be assigned on this logical link. If the rule had been to tie up minimum extra bandwidth, then path would be a-b-c-e-f Or split connection on small-granularity paths

80. 1/25/200580 Bandwidth sharing deconstructed problem in homogeneous network Problem: Should node b accept the call, reject the call or assign it some BW lower than the requested 30Mbps –Simple Complete Sharing (CS) algorithm would say yes! –But from a fairness perspective (short-duration vs. long-duration, short-path vs. long-path), node b may reject the call or give a lower BW level Added dimension: to split call on different routes a c d b e f 2, 30Mbps 5, 100Mbps 1, 150Mbps 1, 10Mbps 1, 50Mbps 1, 500Mbps 2, 50Mbps 1, 50Mbps Request for 30Mbps connection

81. 1/25/200581 Bandwidth sharing deconstructed problem in heterogeneous network Problem: –Tradeoff of fairness and utilization becomes more difficult when these crossconnect granularities are considered a c d b e f 2, 30Mbps 5, 100Mbps 1, 150Mbps 1, 10Mbps 1, 50Mbps 1, 500Mbps 2, 50Mbps 1, 50Mbps Request for 30Mbps connection 1Mbps 51Mbps 10Gbps

82. 1/25/200582 Hop-by-hop vs. source routing I think both can be supported even for QoS- based routing Industry seems to lean toward source routing

83. 1/25/200583 Key ideas Use nested LSPs, each of a uniform multiplexing type (aka switching capability) Advertise “pretend links” to enable other gateways/switches to determine whether they can set up an LSP of a certain type

84. 1/25/200584 Conclusions Is there a protocol to share reachability data from nearest CO switch/gateway to end host – use of LMP? Pretend links – how do nodes automatically recognize need to report these? –From OSPF-TE LSAs on interface switching capabilities, easy to recognize gateways from switches –A gateway reports a pretend link to each other gateway that it can reach with one form of multiplexing –Report current available BW as minimum available BW to each gateway (ignore the fact that if a connection got set up to one gateway, the available BWs drop and hence available BW to another gateway will also drop)

85. 1/25/200585 Conclusions for my original problem What should OCS do? –Useful to bring back MAC address of destination end host? –Determine type of CO path available?

86. 1/25/200586 What software modules need to be developed and deployed e.g., SDM-(VLAN)-(MPLS)-(VLAN)-SDM VLAN multiplexing PATH RESV H1 H2 M H VG H VG VLAN VLSR Pretend link advertiser VLSR Network 1Network 2Network 3 GW1 MPLS multiplexing SW1 GW4 GW3 Cisco GSR SW2 SW3 Internetwork: SDM muxing based network Identify what functionality each gateway box and custom-build gateway GMPLS engine for that box. Leverage software implemented in box. OSPF-TE RSVP-TE Pretend link signaling module See next slide for functional description of pretend link advertiser and pretend link signaling module. Pretend link signaling module Pretend link advertiser Pretend link advertiser Pretend link signaling module Pretend link advertiser Pretend link signaling module OSPF LSA Serves as an RSVP-TE client at an “end host” for this connection OSPF-TE RSVP-TE Update conn. table VLAN VLSR A Cisco GSR has RSVP-TE software as an end client, i.e., an MPLS LER RSVP-TE

87. 1/25/200587 Software for gateways Pretend link advertiser:one per gateway - reads OSPF-TE database, recognize from interfaces on all switches in network 2 that node GW3 is a gateway (links with multiple switching capabilities); this means a pretend link should be advertised between these two gateways. Determine what switching capabilities and rates to advertise for this pretend link based on user-plane gateway capabilities of the box. The pretend links should not be written into the connectivity table of the nodes unless there is software in the nodes to handle these links differently from regular links. Pretend-link signaling module: one per-gateway; if gateway has no RSVP-TE LER (edge) engine to act like an end host client RSVP-TE, then it serves this functionality for the gateway. If the gateway does have this built-in functionality, it simply serves to hold up Path messages headed for the pretend links and invoke the RSVP-TE client software through a CLI/TL1 command to initiate call setup. Thus, it receives RSVP-TE messages, determines if it requires pretend link setup, then issues commands to initiate the set up of the pretend link if not already setup. Then if the box has ability to integrate the newly setup LSP as a FA -LSP, then it transparently passes the SDM RSVP-TE path setup message to the RSVP-TE signaling module built into the gateway. The latter will make the GW2 RSVP-TE signaling module handle it and send one to the GW3 RSVP- TE signaling module; these modules act as the RSVP-TE end host clients for the intra- network connection or as the external trigger for the RSVP-TE client built into the node as an end host client (e.g., the GSR).

88. 1/25/200588 End host first CO node discovery Define a protocol for end host software to broadcast a discover – see if DHCP can be used augmented with usage of some obscure field. Get multiple replies of which nodes have CO capability. Copy routing data from these nodes to know which IP addresses are reachable through what form of CO network: SDM, VLAN or IP. Need to deploy end host software for this purpose as well as software external to CO nodes to respond to end hosts queries. Limit this to an enterprise. If enterprise doesn’t purchase CO service, individual end hosts cannot. So the DHCP discovery of CO capability only spreads up to the WAN access router.

89. 1/25/200589 MAC address software? If sending RSVP-TE client at end host asks for SDM or VLAN call with GPID as Ethernet, then receiving RSVP- TE client at end host responds with MAC address of itself in stacked label. –Question: can Resv message processing at switches simply pass this along? If sending RSVP-TE client at end host asks for CO IP call (2205), then do not return MAC address. Software needed only at end hosts to handle MAC issue, provided intermediate switches simply pass on higher levels of label stacks. Test with SN16000 and Cisco GSR. Test RSVP 2205 set up with GSR.