Operation TF Kotaro/Abas. Discussion Two-UDL 13Mbps Detailed Schedule ASTI Routing (APAN-AI3) UNSYIAH Network Update –Current network situation Diagram.

Operation TF

Kotaro/Abas

Agenda

• 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)

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

Unsyiah Setup

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

Unsyiah Network Topology

Bandwidth Utilization of Two-Hop BDL Sites

ITB-UNIBRAWＤａｉｌｙ

Weekly Monthly

Yearly

ITB-UNSYIAH

• No data..

AIT-TUＤａｉｌｙ

Weekly Monthly

Yearly

Two-hop BDL

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

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

Two-UDL Experiment

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

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

Experiment TopologyFR

RR

Catalyst F

Catalyst R

UDStation

SDM 2020

Upcon

UDbox

Cisco B

Cisco B

SDM 300A

SDM 300A

EthernetSerialCoax

1

2 3

1

2 3

Two-UDL Fallback Plan

sfc-sat2 udl-feed

bdl-gw rr

GW

128k 512k or 1M

13M

Comments? Ideas?

Proposal from USM?

Reviewing AI3 and SOI Asia Agreement

AI3 and SOI Asia Agreement (1/3)

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

AI3 and SOI Asia agreement (2/3)

AI3 team is to operate the network following priority policy[E1] is for the emergency sitesSOI-ASIA multicast traffic [S1][S3] is for everyonePolicy routing [P1] is to be operationalThere 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

AI3 and SOI Asia Agreement (3/3)

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

Proposal Agreement

AI3 and SOI Asia Agreement (1/3)

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

AI3 and SOI Asia agreement (2/3)

AI3 team is to operate the network following priority policy[E1] is for the emergency sitesSOI-ASIA multicast traffic [S1][S3] is for everyoneTransit 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

AI3 and SOI Asia Agreement (3/3)

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

Comments?

UDL Policy Implementation

HFSC Terms

• Guaranteed rate– 1Mbps = can use up to 1Mbps without any loss

• Link share percent– 10% = can use 10% of the available bandwidth

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%

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%

ALTQ Web Config

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

Comments?

UDbox Status

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

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

13Mbps Status

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

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

Padding and Section Packing

Padding

Section Packing

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

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

Bandwidth Allocation for Future Operation

Other Topics for Discussion

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

Upgrade to FreeBSD 6

• FreeBSD 4 is legacy

• Ask SOI Asia interns to help study the feasibility to upgrade SFC hosts to FreeBSD 6

ToDo from Site Update

Summarizing Site Update

ToDo based on Site Update