Transcript Document
End-host Initiated GMPLS Signaling Demo Xiangfei Zhu [email protected] Dynamic circuit setup and release demonstration • Developed a software program called circuitrequestor for CHEETAH end hosts • Usage: – User logins to a CHEETAH end host – Requests the setup of a dedicated 1Gb/s EthernetSONET-Ethernet circuit to another CHEETAH end host – Runs application, such as file transfer – Uses circuit-requestor program to release circuit CHEETAH end-host software – includes circuit-requestor + daemons DNS server End host DNS lookup Circuit-requestor Application OCS client socket CD API CHEETAH Daemon (CD) RSVPD API socket C-TCP API User space Kernel space C-TCP Steps: •DNS lookup (to support our scalability goal) •Circuit setup signaling procedure (RSVP-TE) RSVP-TE Daemon (RSVPD) RSVP-TE messages Demo configuration NYC HOPI Force10 UVa H Mvstu6 152.48.249.106 NCSU UVa Catalyst 4948 1G 2x1G MPLS tunnels NCSU M20 Orbitty Cluster ORNL PoP Force10 E300 switch 1G Wukong 152.48.249.102 H 1GFC UCNS 1G X1(E) 3x1G VLAN OC192 1G Centuar FastIron FESX448 H OC192 GbE 1G 1G GbE Zelda4 10.0.0.14 H Zelda5 10.0.0.15 H 1G 1G 1-8-33 1-8-34 1-6-1 1-7-1 1-8-35 1-8-36 1-8-37 1-6-17 1-7-17 1-8-38 10GbE OC192 1-7-33 1-7-34 1-7-35 1-7-1 1-8-1 1-7-36 1G Juniper T320 1G 1G 1G MCNC Catalyst 6500 1G 1-8-39 Cheetah-ornl OC-192 lamda H Wuneng 152.48.249.103 cheetah-nc Raleigh PoP Atlanta PoP Zelda1 10.0.0.11 H Zelda2 10.0.0.12 H Zelda3 10.0.0.13 H 2x1G MPLS tunnels 1G 1G 1G 1G 1G Juniper T320 1G GbE 10GbE OC192 1-7-33 1-7-34 1-7-35 1-6-1 1-7-36 1-7-1 1-7-37 1-7-38 1-6-17 1-7-39 Cheetah-atl OC-192 lamda Direct fibers VLANs MPLS tunnels WASH HOPI Force10 WASH Abilene T640 CUNY Foundry 1G H 1G H cuny-h1 cuny-h2 134.74.17.112 134.74.17.113 CUNY Circuit-requestor usage – To setup a new circuit: circuit-requestor setup domain-name-of-called-host bandwidth [holding-time] • Default holding-time: 10 mins • Max holding time: 1 hour • Limit call holding time for fair bandwidth sharing – To renew an existing circuit: circuit-requestor renew session-id [new-holding-time] • Release unused circuits if there is no renewal – To release an existing circuit: circuit-requestor release session-id – To check the status of the CHEETAH trunk: circuit-requestor status Measurements Signaling delays incurred in setting up a circuit between zelda1 and wuneng across the CHEETAH network. Circuit type End-tend circuit setup delay (s) Processing delay for Path message(s) at sn16k-nc Processing delay for Resv message(s) at the sn16k-nc OC-1 0.166103 0.091119 0.008689 OC-3 0.165450 0.090852 0.008650 1Gb/s EoS 1.645673 1.566932 0.008697 Round-trip signaling message propagation plus emission delay between sn16k-atl and sn16k-nc: 0.025s Why the initial DNS lookup? • Verify called end host is on CHEETAH network and to obtain MAC address of the second (CHEETAH) NIC • Why is MAC address necessary? – Need to program ARP table to avoid wide-area ARP lookups IP and MAC addressing issues • Our completed Control-Plane Network Design document describes – Why we chose static public IP addresses for the second (CHEETAH) NICs at end hosts • Choose addresses based on CHEETAH host’s location – i.e., allocate address from enterprise’s public IP address space allocation (e.g., UVA hosts: 128.143.x.x) – Reason: Scalability • Impact: – After dedicated circuit is setup: • far end NIC has IP address from a different subnet • Default setting of IP routing table entries will indicate that such an address is only reachable through the default gateway Our solution: automatically update IP routing and ARP tables • Update IP routing and ARP tables at both end hosts as last step of circuit setup – Analogous to switch fabric configuration • Routing table update – Add an entry indicating the remote host is directly reachable through the second (CHEETAH) NIC • ARP table update – Add an entry for the MAC address of the remote CHEETAH NIC Addressing in the CHEETAH network • Whether private and/or dynamic IP addresses can be assigned to the data-plane and control-plane interfaces in GMPLS networks? – Data-plane Addresses • Static – Need to be “called” by other clients • Public – Globally unique – Scalable to multiple autonomous-systems » Private IP addresses sufficient if goal for CHEETAH is to create a small eScience network – Control-plane Addresses • Static – Configured in Traffic-Engineered (TE) link • Public – Same scalability reason