1 / 51

Operation TF

Operation TF. Kotaro/Abas. Brief summary of operation since the last meeting (abazh) Network Events and Incidents (abazh) Unsyiah Setup (abazh) Two-Hop BDL (abazh) UDbox Status (kotaro) Two-UDL Experiment (kotaro) UDL 13Mbps Status (kotaro).

mahala
Download Presentation

Operation TF

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. Operation TF Kotaro/Abas

  2. Brief summary of operation since the last meeting (abazh) Network Events and Incidents (abazh) Unsyiah Setup (abazh) Two-Hop BDL (abazh) UDbox Status (kotaro) Two-UDL Experiment (kotaro) UDL 13Mbps Status (kotaro) Bandwidth Allocation for Future Operation (haruhito) Reviewing AI3 and SOI Asia Agreement (kotaro) Proposal Agreement UDL Policy Implementation (kotaro) ToDos based on Site Update (all) Agenda

  3. Network Events and Incidents • 22 Oct 2005: UNSYIAH started operation • 9 Nov 2005: IOIT advertised IPv6 default route • 18 Jan 2006: UDL Feed trouble • 21 Jan 2006: SFC stopped transmission due to heavy snow • 9 Mar 2006: JCSAT-3 maintenance, all stopped • 16 Mar 2006: JCSAT-3 trouble • 18 Mar 2006: Unibraw SMTP open-relay • 7 Apr 2006: UDL Feed trouble • 12 Apr 2006: 13Mbps UDL test

  4. Unsyiah Setup

  5. Unsyiah Setup • In cooperation with WIDE, KEIO, JSAT and ITB • Unsyiah – SFC BDL (512k/512k) • UDL using SONY box • Started operation 22 Oct. 2005 • Unsyiah – ITB BDL during classes • Started March 2006

  6. Unsyiah Network Topology

  7. Bandwidth Utilization of Two-Hop BDL Sites

  8. ITB-UNIBRAW Ｄａｉｌｙ Weekly Monthly Yearly

  9. ITB-UNSYIAH • No data..

  10. AIT-TU Ｄａｉｌｙ Weekly Monthly Yearly

  11. Two-hop BDL

  12. Current Status • AIT – TU (128k/128k) • ITB – Unibraw (512k/128k) • Becomes ITB – Unsyiah (512k/512k) During ITB-Unsyiah classes by changing Rx freq • Continue to do two-hop BDL? • Or connect them to SFC

  13. Issues in Connecting to SFC • Modem • SFC has spare modems to accommodate both sites • What to do with modems at AIT and ITB? • Address • ITB – Unibraw BDL uses ITB address • Changing links (ITB-Unsyiah class) • Must to UAT before and after each class • SFC stops transmission to give a freq for ITB transmission

  14. Two-UDL Experiment

  15. Two-UDL Experiment • Result: Failed • Cisco bridge at BDL doesn’t forward Ethernet frames due to MAC learning • MAC filtering at catalyst doesn’t help • Fallback Plan as solution based on the current situation • SFC transmit 128Kbps • Minimum just for routing protocol exchange • Partner transmit 1Mbps/0.5Kbps • Feedback and commodity from partner site • Design the routing so that traffic goes from SFC to partner via UDL, and from partner to SFC via BDL

  16. Objective • Reduce BDL bandwidth by: • Using the current BDL as UDL from partner to SFC, and • Using UDL as the forward path from SFC to partner SFC Router Partner Router

  17. Experiment Topology FR 1 Catalyst F 2 3 UDStation Cisco B SDM 2020 SDM 300A Upcon SDM 300A UDbox Cisco B 2 3 Catalyst R Ethernet 1 Serial RR Coax

  18. Two-UDL Fallback Plan sfc-sat2 udl-feed 13M 128k 512k or 1M bdl-gw rr GW

  19. Comments? Ideas? Proposal from USM?

  20. Reviewing AI3 and SOI Asia Agreement

  21. AI3 and SOI Asia Agreement (1/3) • Traffic Classification and Priority [S1] SOI-ASIA lectures [S2] SOI-ASIA related traffic (web, etc.) [S3] SOI-ASIA multicast transfer (MTM) [P1] Policy routed traffic [P2] UDL prefix’s generated traffic [M1] Traffic for network management [E1] Traffic for Emergency situations

  22. AI3 and SOI Asia agreement (2/3) AI3 team is to operate the network following priority policy [E1] is for the emergency sites SOI-ASIA multicast traffic [S1][S3] is for everyone Policy routing [P1] is to be operational There is no need to generate unnecessary traffic from UDL prefixes [P2] Limit the use to certain clients [S2] Management of traffic priority should be decided by AI3 operational team The definition of emergency traffic should be decided jointly by SOI-Asia steering committee and AI3 directors

  23. AI3 and SOI Asia Agreement (3/3) • Satellite transponder capacity and the cost • The carrier bandwidth allocation of satellite transponder and the traffic priority should be reviewed and agreed by AI3 directors meeting and SOI Asia steering committee every six months. • If any changes are necessary, the decision is to be made at the AI3 directors meeting.

  24. Proposal Agreement

  25. AI3 and SOI Asia Agreement (1/3) • Traffic Classification and Priority [S1] SOI-ASIA lectures [S2] SOI-ASIA related traffic (web, etc.) [S3] SOI-ASIA multicast transfer (MTM) [P1] Transit Traffic to Specific AS [P2] Traffic Generated within AI3 AS (P1) Commodity Traffic [M1] Traffic for network management [E1] Traffic for Emergency situations

  26. AI3 and SOI Asia agreement (2/3) AI3 team is to operate the network following priority policy [E1] is for the emergency sites SOI-ASIA multicast traffic [S1][S3] is for everyone Transit Traffic to Specific AS[ P1] There is no need to generate unnecessary traffic from UDL prefixes [P2] Limit the use to certain clients [S2] Management of traffic priority should be decided by AI3 operational team The definition of emergency traffic should be decided jointly by SOI-Asia steering committee and AI3 directors

  27. AI3 and SOI Asia Agreement (3/3) • Satellite transponder capacity and the cost • The carrier bandwidth allocation of satellite transponder and the traffic priority should be reviewed and agreed by AI3 directors meeting and SOI Asia steering committee every six months. • If any changes are necessary, the decision is to be made at the AI3 directors meeting.

  28. Comments?

  29. UDL Policy Implementation

  30. HFSC Terms • Guaranteed rate • 1Mbps = can use up to 1Mbps without any loss • Link share percent • 10% = can use 10% of the available bandwidth

  31. Current ALTQ 9M No-Class TOTAL 8800k / 100% • Control traffic 250k / 5% • routing, SNMP, SSH • SOI-ASIA multicast 2M / 10% • SOI-ASIA unicast 250k / 5% • Policy Routing 3M / 40% • UDL prefix 1M / 30%

  32. Current ALTQ 9M Class TOTAL (8800-X)k / 100% • Control traffic 250k / 5% • routing, SNMP, SSH • SOI-ASIA class • Multicast 5 M / 10% • Unicast 250k / 5% • Others 1.5-X M / 75%

  33. ALTQ Web Config

  34. Proposals • After Two-UDL transition • Stop Policy Routed Traffic • For 13M - Allocate additional bandwidth into P1 & P2 • For Emergency • To be allocated by following the guideline which will be decided later

  35. Comments?

  36. UDbox Status

  37. UDBox Status • Total 12 Boxes • 6 Shipped to Partner • ITB/AIT/ASTI/USC/USM/AIMST • AIT has trouble on the BOX • 1 Operational in SFC • 3 Stocked in SFC • 2 Broken in SFC • SONY Box operation on UDL • More than 10

  38. Proposal on UDL Receiver • Purchase additional UDbox to distribute to SONY-Box partners • No technical support available for SONY-* • 13Mbps + Standard codec • Need Section Packing mode of MPEG-2 TS • ULE(?) as a light-weight data link protocol

  39. 13Mbps Status

  40. UDL 13Mbps Status • Status: Not completed yet • Failure on SFC SONY-Feed • Suitable configuration not implemented • No technical support • Failure on JSAT SONY-Feed • Suitable configuration not implemented • Availability unknown for technical support • Failure on UDStation • JSAT codec not completed (Need padding for SONY-BOX) • Modify to activate Pdding on UDStation

  41. What is the cause of failure? • JSAT codec is not completed on UDstation • UDstation uses packing • Padding is not available on SONY-Receiver, which causes packet loss on SONY-Receiver when it receives traffic • What is padding / section packing? • What does UDStation (Section Packing) causes on SONY-RECV (Padding-only)? • Performance / Interoperability Problem? • When we send packet no to cause section packing… • UDStation -> UDbox is Good • UDStation -> SONY-box is bad

  42. Padding and Section Packing Padding Section Packing

  43. Direction • Wait for UDstation completing the JSAT codec • Migrate to UDstation from SONY-FEED • Migrate to 13Mbps • Feed: UDstaion • Receiver: SONY-BOX + UDbox • Be careful not to disturb SOI-Asia Classes • Detail is in the next page

  44. Todos & Schedule • ~ Beginning of May • Complete JSAT codec on UDStation to migrate from SONY-Feed • ~ Middle of May • Test 13Mbps configuration in IF Environment • UDstation in mixed environment • SONY-Recv + UDBox • ~ End of May • Fix the new bandwidth allocation for 13Mbps with Two-UDL fallback plan • Finalize the instruction for 13Mbps migration • Beginning of June ~ • Ready for 13Mbps Migration in RF • Concern on SOI-Asia classes

  45. Bandwidth Allocation for Future Operation

  46. Other Topics for Discussion

  47. Routing • Unicast • Redesign to incorporate two-UDL • Cost recalculation + BGP redesign(?) • Multicast • Wait for XORP to support SSM • M6bone: wait for WIDE Fujisawa NOC to be ready; MBGP peer with WIDE • Hardware addition • Use cisco from WIDE Fujisawa NOC as sfc-gate and also MBGP peer with APAN-JP • Current sfc-gate becomes backup

  48. Upgrade to FreeBSD 6 • FreeBSD 4 is legacy • Ask SOI Asia interns to help study the feasibility to upgrade SFC hosts to FreeBSD 6

  49. ToDo from Site Update

  50. Summarizing Site Update

More Related