Proceedings (PDF) - Internet Engineering Task Force

PROCEEDINGS OF THE THIRTEENTH 

INTERNET ENGINEERING TASK FORCE 

APRIL 11-14, 1989 

COCOA BEACH, FLORIDA 

Compiled 

and Edited 

by 

Phill Gross 

Karen L. Bowers 

May 1989

Acknowledgements 

The Thirteenth IETF Meeting was held at the Cocoa Beach 

Hilton and Towers at Cocoa Beach, Florida on April 11-14, 

1989. On behalf of the IETF I would like to thank Susie 

Karlson (ACE) for making this a successful and smooth running 

session; she was .faced with many a challenge in a somewhat 

"user hostile" hotel setting and came through with flying 

colors. A special thanks to you, Susie, for the great on 

site support!! 

Though we were unable to make use of the conference 

facilities at the training center of the Kennedy Space 

Center, we certainly enjoyed being sponsored by the 

hospitable Dave Roberts (NASA EL-ESS-4 Office). Dave and his 

associates, Dale Pope, Dick Batton and Jack Martin personally 

treated us to a VIP tour of the KSC. Logistics were 

orchestrated by Mitch Barnes of the Public Affairs Office. 

Thank you all for the first class touch this tour placed on a 

very productive four day meeting. 

The final thank you goes again to Monica Hart (NRI) whose 

relentless efforts have greatly improved the format and 

quality of these Proceedings. 

Karen L. 

Bowers

Table of Contents 

II. 

III. 

IVo 

V. 

Chairman’s Message .................................... 

page 1 

Chairman’s Luncheon ................................... 

page 

IETF Attendees ....................... 

..... page 19 

Final Agenda ................................. 

......... page 31 

Working Group Summaries ............................... 

page 37 

Alert Management 

...................................... page [39 

Authentication ............................... 

.......... page 43 

CMIP-0ver-TCP .................................... 

...... page 49 

Domain 

................................................ page 51 

Dynamic Host Configuration ............................ 

page 57 

Host Requirements ..................................... 

page 6;3 

Interconnectivity ..................................... 

page 615 

Internet MIB 

....... page 618 

JOMANN ....................... 

......................... page 70 

LAN Manager ................................. 

.......... page 74 

Network Information Services Infrastructure (NISI) .... page 84 

Network Management Services Interface ................. 

page 90 

NOC-TOols ................................. 

............ page 94 

Open SPF-based IGP 

.................................... page 102 

Open Systems Routing .................................. 

page 106 

OSI ................ 

............ ¯ °page 1(38 

PDN Routing .................... page 

Point-to-Point Protocol 

................................ page 150 

ST and Connection IP ............................... 

..... page 162 

Telnet Linemode ....................................... 

page 17’2 

User Documents 

........................................ page 174 

User Services 

............ ............................. page 178

Page 2 

Table of Contents 

VI. 

Network Status Briefings and Technical Presentations ..page 186 

Everything You Ever Wanted to Know About OSPFIGP 

(John Moy) .................. ¯ ........................ page 188 

The Open Routing Architecture (Marianne Lepp) ......... page 204 

Report on the NASA Science Internet (Milo Medin) ...... page 212 

State of the Internet (Zbigniew Opalka) ............... page 232 

Growth of the Internet (Mike St. Johns) ............... page 244 

Report on the DOE Energy Science Network (Tony Hain) ..page 250 

An Interim Routing Architecture (Russ Mundy) .......... page 262 

Architectural Changes to the NSFNET (Elise Gerich) .... page 266 

Nifty NSFNet Statistics (Elise Gerich and Dave Katz) ..page 290 

Inter Autonomous System Routing Alternatives 

(Yakov Rekhter) ..................................... page 302 

Requiem for the Arpanet (Vinton G. Cerf) .............. page 308 

Arpanet Evaporation Timetable (Phill Gross) ........... page 313 

Mailbridge Access Control (Marianne Lepp) ............. page 321 

The DCA TCP/IP Certification Program (Martin Gross) ...page 327 

Header Compression for TCP/IP Datagrams (Van Jacobson).page 343 

VII. 

Papers Distributed at IETF ............................ page 359 

Internet Cluster Addressing and Its Application to 

Public Data Networks ................................ page 361 

Hierarchial Van-Gateway Algorithms and PDN-Cluster 

Addressing Scheme for Worldwide Interoperation 

between Local TCP/IP Networks via X.25 Networks ..... page 371 

NVLAP Program Handbook: Computer Network Interface 

Protocols/DOD High Level Protoco].s (Requirements 

for Accreditation) .................................. page 381 

Executive Summary: Cornell Worm Report ............... page 403

I. Chairman’s Message 

Phill Gross 

NRI

Chairman’ s Message 

An Important 

Anniversary 

The April II-14 1989 meeting of the IETF coincided closely with the 

anniversary of a significant event. On April 7, 1969, RFC 1 was issued. 

The title was "Host Software" 

¢ 

and the author was Steve Crocker 

It was interesting to read this paper from a twenty.year vantage 

point. 

Quoting from RFC l: 

"Introduction 

The software for the ARPA network exists partly in the IMPs and 

partly in the respective HOSTs. BB&N has specified the software in the 

IMPs and it is the responsibility of the HOST groups to agree on the 

HOST software. 

During the summer of 1968, representatives from the initial 

four sites met several times to discuss the HOST software and 

initial experiments on the network. There emerged from these 

meetings a working group oo. 

I present here some of the tentative agreements reached and some of 

the open questions encountered. VERY LITTLE OF WHAT IS ]~ERE IS FIRM 

[emphasis added] and reactions are expected .... 

Some Requirements Upon the Host-to-Host Software 

... As with any new facility, there will be a period of very light usage 

until the community of users oo begins to depend on it. . . It seems 

natural to provide the abilit~ to use any remote HOST as i~ it had been 

dialed from a TTY (teletype) terminal° Additionally, we would like some 

ability to transmit a file in a somewhat different manner perhaps than 

simulating a teletype .... 

One of the inherent problems in the network is the fact that all 

responses from a remote HOST will require on the order of a half-second 

or so, no matter how simple. For teletype use, we could shift to a 

half-duplex local-echo arrangement, but this would destroy some 

of the usefulness of the network." 

Working Groups, host requirements (unfirm host requirements, we should 

note!), and the expectation that a community of users will grow to 

depend on network communication -- there is much prophesy in this 

first RFC! We can also see the roots of TELNET and FTP. 

In reading RFC l, I was struck by how much has changed over 20 years, 

and yet how many of the challenges and fundamental problems remain today. 

Twenty years ago there were four IMP sites on the world’s only packet 

switching network. Today there are 10’s of 1000’s of hosts and 100’s 

of 1000’s of users reachable on an international Internet of low-1000’s 

of networks. The growth of the !ETF has mirrored that pattern. The

Page 2 

Chairman’s 

Message 

group had its origins in a 15 person working party of government contractors 

in the mid-80’s. Typical meetings are now nearly ten times that large 

with a large vendor and user constituency. When we first formed 

working groups, there were four; now there are 22 with several others 

in various stages of formation. Of these working groups, the IETF 

currently has a working group still attempting to firm up host rquirements 

and the Telnet WG is still dealing with the issue of a line oriented 

local-echo. 

However, the continued need for such groups is more an indication of the 

incredible growth and change in the environment, rather than an indication 

of a lack of progress. We have always been victimized, by the growth and 

demand created by the abundance of technical success, rather than the lack 

of success. So, challenges certainly remain. But judging from the 

particularly sharp technical progress in recent meetings, I believe we 

have the right to celebrate this notable anniversary in style. 

(Thanks to Bob Braden (ISI) for noting the anniversary of RFC 

Another Significant Milestone 

At the June 1988 IETF meeting in Annapolis, Mark Pullen of DARPA renorted 

that the Arpanet was being decon~nissioned. Plans for this remarkable 

event have become firm, and the initial actions are being taken. The 

Arpanet Evaporation schedule, as provided by DARPA, was reported at 

the April 1989 meeting. The slides speak for themselves, and little needs 

to be added. However, Vint Cerf, considered by many to be the father 

of the Arpanet, has provided a touching perspective on the subject. Please 

enjoy. 

The April 1989 Meet’ing 

Fifteen Working Groups met at the Cocoa Beach IETF. Two new WGs 

met for the first time. These new groups are the NOC Tools catalogue 

WG and the Dynamic Configuration WG. Another experimental WG to examine 

a possible unified network management interface also met for the first time, 

but it has not yet been decided to continue that effort. Since April, two 

other groups have formed under the auspices of the User Services WG. These 

are the Network Information Services Infrastructure WG and the User 

Documents bibliography WG. Descriptions and reports on all these activities 

are contained in these Proceedings. 

Three other WGs had progressed to the point of making detailed 

technical reports to the Plenary. These WGs are Interconnectivity, 

Open Routing, and Open OSF Routing. There was even a minority 

report to the IWG’s proposal for a mid-term routing architecture. 

Just prior to the April meeting, Cornell released "Tihe Computer Worm" report 

resulting from an internal investigation. Jeff Schiller, who had previewed 

the report, was kind enough to give an unscheduled, di.scussion of that report 

to the Plenary. The conclusion section of the Cornell report has 

been included in these Proceedings° 

-4-

Page 3 

Chairman’s 

Message 

Other News 

Responding to a vote of attendees at the January 1989 IETF meeting in Austin 

Texas, the April meeting was extended to 3.5 days. The first two days 

were devoted fully to Working Grohp sessions, the third day was devoted 

fully to technical presentations, and the concluding half day was devoted 

to reports from the Working Groups. This increased the number of sessions 

for working group meetings, where much of the technical work. is pursued, 

from three to four. 

At the April meeting in Cocoa Beach, we held a luncheon for the Working 

Group chairs to receive feedback on this and other actions (See Section 

II for more details). At this luncheon, a second refinement was suggested 

to give even more time for Working~Groups activity. Tihe suggested schedule 

was: 

Days l and 2 

9 am - 12 WG Morning session 

1 pm - 4 pm WG Afternoon session 

4 pm - 5:30 pm Technical Presentations (in Plenary) 

Day 3 

9 am - 12 WG Morning session 

1 pm - 5:30 pm Technical Presentations (in Plenary) 

Day 4 

9 am - 12 WG Reports 

This gives an additional period for WG sessions, making a total of five 

sessions, but retains the overall time available for technical Plenary 

presentations. This will reduce the number of overlapping WGs meetings. 

This format will be tried as an experiment at the next several meetings. 

-5-

IETF Working Group Status 

(April 1989) 

Working Groups 

ALERTMAN 

Authentication 

CMIP-over-TCP (CMOT) 

DNS (new) 

Dyn. Host Config. (new) 

Host Requirements 

Interconnectivity 

Internet MIB 

JoMann/NSFnet Req Mon. 

LAN Mgr MIB 

NISI (new) 

NM Ser Interface 

NOC Tools (new) 

RFC or Met Current, 

Draft? Apt 89? Report? 

Yes 

Yes 

Yes Yes Yes 

Yes No - 

Yes Yes Yes 

Yes 

Yes 

Yes No - 

Yes Yes Yes 

Yes No - 

Yes Yes Yes 

No Yes Yes 

May 89 Yes 

Yes 

Yes 

Yes 

Yes 

Chair or POC 

(address) 

Louis Steinberg 

louiss@ibm.com 

(IBM) 

Jeff Schiller (MIT) 

j is@athena, mit. edu 

Jon Rochlis (MIT) 

j on@athena, mit. edu 

Lee LaBarre (MITRE) 

cel@mitre.org 

Paul Mockapetris 

pvm@isi.edu 

(ISI) 

Ralph Droms (Bucknell) 

droms@cs.purdue.edu 

Bob Braden (ISI) 

braden@isi.edu 

Guy Almes (Rice) 

almes@rice.edu 

Craig Partridge (BBN) 

craig@nnsc.nsf.net 

Susan Hares (Merit) 

skh@merit.edu 

Amatzia Ben-Artzi (Stan) 

amatzi@spd. 3mail. 3com. corn 

Karen Bowers (NRI) 

bowers@sccgate.scc.com 

Phill Gross (NRI) 

gross@sccgateoscc.com 

Jeff Case (UTK) 

case@utkcs2.cs.utk.edu 

Bob Enger (Contel) 

enger@sccgate.scc.com 

-7-

IETF Working Group Status 

Page 2 

Working Groups RFC or Met Current 

Draft? Apr 89? Report,? 

Chair or POC 

(address) 

OSPF 

Yes Yes Yes 

Mike Petry (UMD) 

petry@trantor, umd. edu 

John Moy (Proteon) 

jmoy@proteon.com 

Open Systems 

Routing 

Yes Mar 89 

Marianne Lepp (BBN) 

mlepp@bbn.com 

OSI Interoperability 

No Yes Yes 

Ross Callon (DEC) 

callon@erlang.dec.com 

Rob Hagens (UWISC) 

hagens@cs.wisc.edu 

PDN Routing 

Group 

No Yes YES 

CH Rokitansky(Fern 

roki@isi.edu or 

roki@dhafeu52.bitnet 

Univ) 

Performance 

and CC 

Yes Yes Yes 

Allison Mankin (MITRE) 

mankin@gateway.mitre.org 

Pt-Pt Protocol 

Yes Yes Yes 

Drew Perkins (CMU) 

ddp@andrew, cmu.edu 

Russ Hobby (UC Davis) 

rdhobby@ucdavis.edu 

ST and CO-IP 

No Yes Yes 

Claudio Topolcic 

topolcic@bbn.com 

(BBN) 

TELNET Linemode 

Yes No Yes 

Dave Borman (Cray) 

dab@cray.com 

User Documents 

(new) 

Jun 89 Yes 

Karen Roubicek (NSF) 

roubicek@nnsc.nsf.net 

Tracey LaQuey (UTexas) 

tracy@emx.utexas.edu 

User Services 

No Yes Yes 

Karen Bowers (NRI) 


Future IETF Meetinq 

Sites 

25-28 July 1989 

31 Oct - 3 Nov 1989 

6-9 February 1990 

1-4 May 1990 

31 Jul - 3 Aug 1990 

~,~ovember 1990 

February 1991 

Stanford University 

University of Hawaii 

Florida State University 

Pittsburgh Supercomputer Center 

University of Washington 

Princeton 

OPEN - VOLUNTEERS encouraged! ! 

-8-

II. Chairman’s Luncheon 


NRI 

-9-

The Corporation for National Research Initiatives has a 

cooperative agreement with the National Science Foundation to 

provide overall technical guidance to the IETF. This technical 

guidance includes IETF high-level planning and direction, 

identification of Internet issues, and organization and guidance 

to appropriate Working Groups to address these issues. In order 

to concentrate our efforts more fully on the primary goal of 

technical guidance, we embarked on a short-term effort "to 

streamline such administrative necessities as Proceedings 

preparation, quarterly meeting planning, and working group 

reporting. 

A luncheon for Working Group chairs was held on April 12, 1989. 

The purpose of this session was to provide all Working Group 

chairs with essential information on how these new procedures 

would facilitate their technical reporting and distribution of 

information. 

The Chairman’s Luncheon briefing outlined the current IETF and 

Internet-Draft Directory activities and contents; the procedure 

employed in preparation of the Proceedings and the associated 

formats for the WG Charter (Form 2), the Status Update (Form 

and Current Meeting Report; and an overview of activity in 

progress between the quarterly IETF meetings (slides attached). 

Two distinct directories, the IETF Directory. and the Internet 

Drafts Directory, will be maintained on line ~o better facilitate 

progress of the IETF and to provide public access to information 

important to IETF members and newcomers alike. 

The IETF Directory (to be in place shortly) will consist of files 

containing: a general IETF description, the Working Group Matrix, 

meeting dates/locations, current meeting information, a READ ME 

file with a high level overview of the IETF Directory, and 

individual Working Group files. Each Working Group will have a 

file dedicated to its particular activities and will contain a 

Charter (Form 2), a Status Update (Form 3) and the most Current 

Meeting Report. 

The Internet-Draft Directory (in place now) is a repository 

working Internet-Drafts made available for review and comment,in 

preparation for transition to full RFC status, as appropriate. 

This directory will soon contain a READ ME file and Index- 

Abstract to aid the reader in locating files of interest and 

points of contact for each Internet-Draft. Internet-Drafts ar.e 

installed as they are made available to the IETF Office and are 

done so in RFC format, to facilitate document submission to the 

RFC editor. Eleven Internet Drafts are currently installed inthe 

Internet Draft Directory; nine are queued up to be installed 

shortly. 

The procedures for preparation of the quarterly IETF Proceedings 

are currently under revision. The goal is to better capture the 

accomplishments of the individual Working Groups as well as 

improve the quality and format of the document itself. This

includes timely distribution of the Proceedings to the Working 

Group Chairs and IETF meeting attendees. To assist in this 

process all Working Group Chairs and technical briefers are 

requested to provide their input as soon as possible upon their 

return home from the IETF meeting, preferably within the fiu~t 

two weeks. Their early submission will result in an expeditad 

release of the Proceedings to the printers and in turn to WG 

Chairs, IETF attendees and the like. 

Activity between the quarterly meetings is ongoing. WG Chairs 

hold interim meetings and video teleconferences; WG member3 

continue their work on identified priorities; mid-term meeting 

reports are submitted to the IETF Chairman; new and revised 

Internet-Drafts are installed in the Internet-Draft Directory; . 

the agenda for the next IETF ~.~uarterly meeting is drafted and 

finalized through joint participation of all the WG Chairs; and 

arrangements for the next quarterly IETF meeting are announced 

and finalized. 

This is an iterative process, which when firmly in place, will 

greatly assist the IETF’s primary technical mission. 

Karen L. 

Bowers

-13-

0 

~=~ 

+~ 0 

D 

-14-

III. 

IETF Attendees

0 

~.~ 

0 

~r~O 

.~ o~ o~1 o’~ o 

~ I 

,-4 

-2i-

-22- 

0

0 0 

-24-

-25-

o~ 

0 

0 

,,~

0 

~27-

-2 8-

-29-

IV. Final 

Agenda

Agenda for the April 11-14 IETF Meeting 

TUESDAY, 

APRIL llth 

9:00 am Opening Plenary, Introductions and iLocal Arrangements 

Phill Gross (NRI) 

9:15 am Morning Working Group Sessions 

o OSPFIGP (Petry, UMD and Moy, Proteon) 

o Network Management Services Interface 

(Case, UTK and McCloghrie , TWG) 

o OSI Interoperation (Callon, DEC and Hagens, UWisc) 

o Performance and Congestion Control, TCP Subgroup 

(Mankin, Mitre) 

o Point-Point Protocol (Perkins, ~U and Hobby, 

(UCDavis) 

o User Services (Bowers, NRI) 

12 : ~ 0 pm Lunch Break 

1:30 pm Afternoon Working Group Sessions 

o Authentication (Schiller, MIT and Rochlis, MIT) 

o I2%NMAN (Ben-Artzi, 3Com) 


o Performance and Congestion Control (Mankin, Mitre) 

(Open Meeting, but attendees are expected to 

have reviewed, and prepared comments on, the 

draft Gateway Congestion Control paper. Send 

to mankin@gateway.mitre.org for a copy.) 

o Point-Point Protocol (Perkins, CMU and Hobby, 

(UCDavis) 


5:00 pm Recess (for the those not attending the DMS WG session) 

5:00 pm Domain Name System WG~(convened by Drew Perkins, CMU) 

- 6:30 pm 

-33-

WEDNESDAY, 

APRIL 12th 

9:00 am Opening Plenary 

9:15 am Morning Working Group Sessions 

o NOC Tools (Enger, Contel and Stine, Sparta) 

o Joint Interconnectivity and Open Routing WGs 

(Almes, Rice and Lepp, BBN) 

o Public Data Network Routing (RoMitanski, FERN) 

(Open meeting) 


(Editing session for WG members only) 

o ST and Connection IP (Topolcic, BBN) 

o ALERTMAN (Louis steinberg, IBM) 

12:15 pm Lunch Break 

12:30 pm Working Lunch of the WG Chairs 

o IETF Office Update (Bowers, NRI) 

1:30 pm Afternoon Working Group Sessions 

5:00 pm Recess 

o Host Dynamic Confi.guration (Droms, Bucknell and 

P.Gross, NRI) 

o Interconnectivity (Almes, Rice) 

o Public Data Network Routing (Rokitanski, FERN) 

(Members Only) 


(Editing session for WG members only) 

o ST and Connection IP (Topolcic~ BBN) 

7:30 pm o Joint Monitoring Access for (NSFNET) Adjacent 

Networks 

(Gerich, Merit)

THURSDAY, 

APRIL 13th 

9"00 am Opening Plenary 

9:10 am Everything You Ever Wanted to Know about OSPFIGP 

(including how to pronounce it) (Moy, Proteon) 

10:00 am The Open Routing Architecture (Lepp, BBN) 

10:45 am Break 

ii:00 am Report on the NASA Science Internet (Medin, Ames) 

11:50 am State of the Internet (Opalka, BBN) 

12:10 pm Growth of the Internet (St. ~ohns~ ]8600) 

12:30 noon Lunch Break 

1:45 pm Report on the DOE Energy Science Network (ESNET) 

(Hain, LBL) 

2:00 pm An Interim Routing Architecture (Mundy, DCA B600) 

2:15 pm NSFNET Report 

o Architectural Changes to NSFNET (Gerich, MERIT) 

o Nifty NSFNET Stats, using NNStat (Gerich, MERIT) 

2:45 pm Interim Routing Architecture (an Alternative View) 

(Rekhter, IBM) 

2:55 pm Arpanet Evaporation Timetable and An Overview of 

FRICC Initiatives (eg, the NNT, RIB,. and RIG) 

(P.Gross, NRI) 

3:05 pm Mailbridge Access Control (Lepp, BBN) 

3:15 pm Authentication WG Report (Schiller, MIT) 

3:30 pm Break 

3:45 pm Cornell Worm Report Commentary (Schiller, MIT) 

3:55 pm The DCA TCP/IP Certification Program 

(M. Gross, DCA-DCEC) 

4:15 pm Header Compression for TCP/IP Datagrams 

(Van Jacobson, LBL) 

5:00 pm Recess 

-35-

FRIDAY, APRIL 14th 

9:00 am Opening Plenary 

9:15 am Working Group Reports and Discussion 

10:30 am Break 

o Network Management Services Interface 

(Case, UTK and McCloghrie, TWG) 

o LANMAN (Ben-Artzi, 3Com) 

(Hares, Merit) 


o Joint Monitoring ~ccess for (NISFNET) Adjacent 

Networks 



o Point-Point Protocol (Perkins, CMU and 

Hobby, UCDavis) 

o ST and Connection IP (Topolcic, BBN) 

10:45 am Working Group Reports and Discussion 

o ALERTMAN (Steinberg, IBM) 

o Host Dynamic Configuration (Droms, Bucknell and 

P.Gross, NRI) 

o NOC Tools (Enger, Contel and Stine, Sparta) 

o Domain Name System (Perkins, CMU) 

o Public Data Network Routing (Rokitanski, FERN) 

11:30 pm Concluding Plenary Remarks and Group Discussion 

12:00 pm Adjourn 

-36-

V. Working Group Summaries 

o Charters 

0 

0 

0 

Status Updates 

Current Meeting Reports 

Slides Presented at IETF 

(if available)

Alert Management Working Group 

Chairperson: Louis Steinberg/IBM 

CHARTER 

Description 

of Working Group: 

The Alert Management Working Group is chartered with 

defining and developing techniques to manage the flow 

of asynchronously generated information between a 

manager (NOC) and its remote managed entities. 

The output of this group should be fully compatible 

with the letter and spirit of SNMP (RFC 1067) and 

CMOT (RFC 1095). 

Specific 

Objectives: 

Develop, implement, and test protocols and mechanisms 

to prevent a managed entity from burdening a manager 

with an unreasonable amount of unexpected network 

management information. This will ifocus on controlling 

mechanisms once the information has been generated by a 

remote device. 

o Write an RFC detailing the above, including examples of 

its conforment use with both SNMP traps and CMOT 

events. 

o 

~ 

Develop, implement, and test mechanisms to prevent a 

managed entity from generating locally an excess of 

alerts to be controlled. This system will focus on how 

a protocol or MIB object might internally prevent 

itself from generating an unreasonable amount of 

information; examples of such techniques might include 

limiting number of alerts per time period, delayed 

reporting of "good news" (as in the ].ink up sgmp trap 

on NSFNET), or the use of thresholds. 

Write an RFC detailing the above. Since the 

implementation of these mechanisms is protocol 

dependent, the goal of this RFC would be to offer 

guidance only. It would request a status of 

"optional". 

Estimated Timeframe for Completion: 

A draft of the first RFC (alert flow control) will 

written and reviewed by the July IETF meeting, with final 

review expected at the October IETF meeting. The second RFC 

draft will be submitted for initial review at the October 

IETF meeting. A date for final review of this document has 

not yet been determined.


Chairperson: ]Louis Steinberg/IBM 

STATUS UPDATE 

i. Chairperson: Lou Steinberg~ louiss@ibm, com 

2. WG Mailing list: alert-man@merit, edu and 

alertoman-request@merit, 

edu 

3. Last Meeting (and first): Cocoa Beach, FL, April 12, 1989 

4. Next Meeting: Stanford, July 25-28, 1989 

5. Progress to date: Initial review of topics, defining what 

we are attempting t.o accomplish. 

5. Pending or new objectives: see objectives in Charter 

6. Progress to date (e.g.,, documents produced): 

o initial review of topics and defining what we are 

attempting to accomplish


Chairperson: Louis Steinberg/IBM 

CURRENT MEETING REPORT 

Reported by Louis Steinberg 

AGENDA 

ATTENDEES 

Introduction 

Discussion of group’s charter and goals 

Chair’s action items 

establish mailing list 

write first draftof "information flow management" 

document 

~-Cathy Aronson 

Amatzia Ben-Artzi 

Jeff Case 

John Chao 

John Cook 

Chuck Davin 

Mark Fedor 

Lionel Geretz 

Bob Harris 

Steven Hunter 

Tom Hytry 

Lee Labarre 

Charles Lynn 

Keith McCloghrie 

Bill Norton 

Joel Replogle 

Greg Satz 

Bruce J. Schofield 

John Scott 

Jim Sheridan 

Robert Stine 

Steve Waldbusser 

Dan Wintringham 

cja@merit.edu 

amatzia@spd.3+o3com.com 

case@utkuxl.utk.edu 

jchao@bbn.com 

cook@chipcom.com 

jrd@ptt.lcs.mit,,edu 

fedor@nisc.nyser,,net 

lionel@salt.acc.com 

bharris@bbn.com 

hunter@nmfecc.llnl.gov 

tlh@iwles@att 

cel@mbunix.mitre.org 

clynn@bbn.com 

kzm@twg.com 

wbn@merit.edu 

jr@ncsa.uiuc.edu 

satz@cisco.com 

schofield@edn-vax.dcaomil 

scott@dg-rtp.dg.com 

jsherida@ibm.com 

stine@sparta.com 

sw01@andrew, cmu.edu 

danw@igloo.osc.edu 

MINUTES 

The first meeting of the Alert Management Working Group began 

with an introduction from the Chairman (Lou Steinberg). 

A discussion of the goals of this group then followed. It was 

decided that the output of this group must take great care to not 

impact the letter or spirit of either the SNMP or CMOT RFCs. Each 

document produced will demonstrate the use of proposed alert 

management techniques in a manner conferment with both SNMP and 

CMOT. 

-41-

Page 2 

Alert Management 

Working Group 

Several divisions were proposed for the work’~ to be done. 

Lou discussed his interpretation, in which he focused on (i) the 

flow of previously generate.d alerts and (2) managed MIB objects 

to generate them. Examples of each were briefly cited, as Lou 

has already coded and tested these ideas° 

Jeff Case expressed strong concern that the Working Group not 

focus on managed MIB objects to generate ale.rts. The feeling of 

many SNMP implementors was that this would violate the philosophy 

of SNMP, which uses the protocol (rather than managed objects) 

generate traps. While some SNMP users may be using such objects 

in the experimental space of the MIB, it is inconsistent to 

define such variables. Doing so (even with ’~optional" MIB 

objects), would make the MIB appear to be slanted towards use 

with CMOT. 

Lee LaBarre presented the (.~4IP view of Events, and the areas that 

ISO looks at to manage them. This was basically a superset of 

Lou’s view. 

The desire to develop techniques fully compatible with both SNMP 

and CMOT led to a decision that two RFCs would be submitted. The 

first would deal with managing the flow of information caused by 

asynch, generated alerts. The second (with a requested 

status of "optional") would discuss techniques for generating 

such alerts that are self-limiting; those that do not allow an 

excess of alerts to be generated. 

Lou agreed to set up a mailing list for the group. He did not 

think that ibm.com was available, and agreed to look for an 

alternative (SNMP @ nisc.nyser.net was suggested for a start). 

Lou also took the action item to write up a draft of the first 

("flow") document, describing some of the systems he has used. 

This will be posted to the list for initial review.

Authentication Working Group 

Chairperson: Jeffrey Schiller/MIT 

CHARTER 

Description 


To brainstorm issues relating to providing for the security 

and integrity of information on the Internet, with emphasis 

on those protocols used to operate and control the network. 

To propose open standard solutions to problems in network 

authentication. 

Specific Objectives: 

RFC specifying an authentication format which 

supports multiple authentication systems. 

¯ 

¯ 

Document discussing the cost/benefi,t tradeoffs of 

various generic approaches to solving the 

authentication problem in the Interlnet context. 

Document to act as a protocol designers guide to 

authentication. 

o RFC proposing A Key Distribution System (emphasis on 

"A" as opposed to "THE"). MIT’s Kerberos seems the most 

likely candidate here. 


This working group will hopefully complete its current 

objectives within one year. At this point the group with 

either disband or will move on to other related 

problems/issues. 

-43-



STATUS UPDATE 

Chairperson: Jeffrey Schiller, jis@bitsy.mitoedu 

¯ 

WG Mailing list: 

AWG@BITSY.MIToEDU 

Last Meeting: Cocoa Beach April 1989 

¯ 

Next Meeting: 

To Be Scheduled 

¯ 

Pending or New Objectives: 

o 

Progress to Date (e.g., documents produced): 

A draft RFC was circulated at the last meeting to proposing 

a standard authentication format for multiple protocols 

(addresses object [I] above). 

A draft "Authentication Requirements" document was also 

circulated. This is the beginning of an effort that will 

lead to writing a protocol, designers guide to authentication 

(addresses objective [3 ] above) 

A draft RFC for the Kerberos Authentication system was 

circulated as well (addresses objective [4] above). 

-44-




Reported by Jeffrey Schiller 

ATTENDEES 

-Danny Cohen 

John Cook 

Charles Eldridge 

Hunaid Engineer 

Phill Gross 

Mike Karels 

Steve Knight 

Lee LaBarre 

Norbert Leser 

Louis Mamakos 

Don Merritt 

John Moy 

Russ Mundy 

Jeff Schiller 

Mike St. Johns 

Ross Veach 

Ste~e Waldbusser 

MINUTES 

cohen@isioedu 


eldridge@sparta.com 

hunaid@hall.cray.com 

gross@sccgate.scc.com 

karels@berkeley.edu 

knight@baldmt.cray.com 


nl@osf.org 

louie@trantor.umd.edu 

merritt@brl.mil 

jmoy@proteon.com 

mundy @beast.ddn.mil 

jis@bitsy.mit.edu 

stjohns@beast.ddn.mil 

rrv@uxc.cso.uiuc.edu 

sw01@andrew.cmuoedu 

Three handouts were distributed at the beginning of the meeting,, 

i. First Draft of an Authentication Requirements document 

currently being authored by Jon Rochlis. 

2. A copy of a Draft RFC for Version 4 of the Kerberos 

Authentication System authored by Jennifer Steiner. 

3. A copy of a Draft RFC for a new IP option for IP level 

authentication by Jeffrey Schiller. 

Most of the discussion at the meeting was on the IP option 

draft paper. This paper proposes the creation of a new IP option 

for carrying a cryptographic checksum of selected portions of the 

packet’s IP header and the entire data contents of the packet. 

Its primary use would be as a mechanism to permit the addition of 

authentication to already existing protocols that currently have 

no provision for carrying authentication information within the 

protocol’s own data contents. 

The members of the working group discussed the document and 

proposed several modifications. The meeting came to a consensus 

on the modifications. 

Action Items: 

Jeffrey Schiller will put together another version of the IP 

option document and will distribute it to the members for 

consideration. 

-45-

CMIP-over-TCP 

Chairperson: 

(CMOT) Working Group 

Lee LaBarre/Mitre 

CHARTER 

Description 


Develop a long term approach to management of the 

Internet based on the OSI Network Management Framework 

and the Common Management Information Protocol (CMIP). 

Provide input to the OSI standards process based on 

experience in the Internet, and thereby influence the 

final form of OSI International Standards on network 

management, in particular CMIS/P. 

Specific 

a) 

b) 

c) 

d) 

e) 

f) 

Objectives: 

Develop prototype implementors agreements on CMIP over 

TCP. 

Develop prototype implementations based on the CMOT 

agreements and IETF SMI and MIB agreements. 

Experiment with CMOT and extensions to the SMI and MIB. 

Develop final implementors agreements for CMOTo 

Promote development of products based on CMOT. 

Provide input to the OSI Network Management standards 

process in time to effect the International Standards. 


The group’s work should be completed by June 1989. 

-49-

CMIP-over-TCP (CMOT) Working Group 

Chairperson: Lee LaBarre/Mitre 

STATUS UPDATE 

i. Chairperson: Lee LaBarre, cel@mitre, org. corn 

2. WG Mailing List: netman@gatewayomitre..org 

3. Last meeting: 19 January~ 1989, Austin~ Texas 

4. Next Meeting: TBD as required 

5. Pending or New Objectives: 

The remaining 

tasks for the group include: 

- updating the specification when the OSI standards 

reach international standard (IS) status, 

- specification of ew~nt generation and event report 

control mechanisms. 

The latter task has moved to a subgroup of the MIB WG. 

However, if it is decided that generic event generation and 

report control mechanisms are not desired, then this group 

will address the problem. 

® 

Progress to date (e.g., documents produced): 

o RFCI095, "The Common Management Information Services 

and Protocol over TCP/IP (CMOT", edited by U. Warrier 

and L. Besaw 

The group has completed a major portion of its charter 

to develop a long term approach to network 

management, namely an specification of an architecture 

and protocol that is consistent with OSI and will 

facilitate management of future networks containing 

TCP/IP and OSI components. That specification, 

contained in RFCI095, is based on the DIS version of 

CMIP, and on Internet RFCs. The RFC1095 and the new 

SNMP RFCI098 have been given equal status by the IAB. 

CURRENT MEETING 

REPORT 

None 

-5 O-

Domain Working Group 

Chairperson: Paul Mockapetris/USC/ISI 

CHARTER 

Description 


The goal of the Domain Working Group is to advise on the 

administration of the top levels of the DNS ("the root 

servers"), consider proposed extensions and additions to the 

DNS structure and data types, and resolve operational 

problems as they occur. 


The specific short-term objectives are: 

2. 

3o 

4. 

5o 

6. 

Adding load balancing capability to the DNS. 

Adding DNS variables to the MIB. 

Implementation catalog for DNS software. 

Responsible Person Record. 

Adding network naming capability to the DNS. 

Evaluate short term measures to improve, or at least 

describe the security of the DNS. 

Estimated Timeframe for Completion (for above objectives): 

l® The preferred method for Load Balancing was decided 

upon at the April ’89 IETF meeting at Cocoa Beach. 

short RFC will be written before the next meeting in 

July ’89. 

A 

2. End of 1989 

~ Questionaire sent, responses data being organized, 

sua~mary and detail to appear. (PVM) 

4. July w89. 

5o RFC issued April 89, implementations to follow. 

-51-



STATUS UPDATE 

i. Chairpersons: Permanent - Paul Mockapetris (pvm@isi.edu) 

Temporary - Drew Perkins (ddp@andrew.cmuoedu) 

2. WG Mailing Lists(s): namedroppers@sri-nic.arpa 

3. Date of Last Meeting: April ’89p Cocoa Beach 

4. Date of Next Meeting: July ’89, Stanford University 

5. Pending or New Objectives: see Charter 

6o Progess to Date (e.g., documents produced): 

o RFC ll01 - on Network Name Mapping 

o Advice to Internet Host Requirements Editor 

-52-



CURRENT 

Reported 

MEETING REPORT 

by Drew Perkins 

AGENDA 

What should the DWG suggest 

WG. 

to the Host Requirements 

2. How do DNS processes appear in the MIBo 

3o 

Policy on load balancing. 

ATTENDEES 

4. Addition of dynamic add and delete to the DNS. 

° Firm up the rules for defining new types and classes, 

and the interpretation of wildcards. 

6. Implementation catalog for DNS software° 

7. A test/validation suite for the DNS. 

8. Enhancements to the DNS in general. 

..... Momhammad Alaghebandan 

Philip Almquist 

Cathy Aronson 

Dave Borman 

Mike Collins 

Mark Fedor 

Jose Garcia-Luna 

Elise Gerich 

Mike ~arels 

Steve Knight 

Tracy LaQuey 

Mark. Lotter 

Paul Love 

Russ Mundy 

Bill Norton 

Bill Nowicki 

Drew Perkins 

Rex Pugh 

Mary Stahl 


Zaw-Sing Su 

Paul Tsuchiya 

mra@bridge2.3com, com 

almquist@jessica.stanford.edu 

cja@merit.edu 

dab@cray.com 

collins@ccc.mfecc.llnl.gov 

fedor@nisc.nyser.net 

garcia@sri.com 

epg@merit.edu 


knight@baldmt.cray.com 

tracy@emx.utexas°edu 

mlk@sri-nic.arpa 

loveep@sds.sdsc.edu 

mundy@beast.ddn.mil 

wbn@merit.edu 

nowicki@sun.com 

ddp@andrew.cmu.edu 

pugh%hprnd@hplabs.hp.com 

stahl@sri-nic.arpa 


zsu@sri.com 

tsuchiya@gateway.mitreoorg 

-53-

Page 2 

Domain Working 

Group 

MINUTES 

The Domain WG met at theApril "89 IETF in Cocoa Beach, Fla. 

Since Paul Mockapetris (ISI), the pe].~anent chairman of the 

Domain WG, was unable to attend the meeting, Drew Perkins (C~J) 

filled in as temporary chairman.~ 

The group quickly decided that no one in attendance had any 

strong desires to talk about.any of the issues with the exception 

of Load Balancing. This happened to be the main concern of the 

temporary chairman, so the rest of the meeting was spent 

discussing it. 

The goal of "load balancing" is to use the DNS as a tool to 

dynamically balance the load across some nu~er of servers° The 

particular situation is as follows. There are a number of server 

machines HOST1, HOST2, HOST3, etc. Each of these machines is 

connected to a network file system and appear identical to users 

(with the exception of the host name of course). Users would 

like to simply say "TELNET HOST "~ and be connected to the least 

loaded host° It was decided that there were a nu~tber of ways of 

accomplishing this, most of them using the DNS. 

i. The TELNET application could use some protocol to find out 

the load across all servers whenever a user wanted to 

connect to a server. It could then pick the least loaded 

system. This of course has the disadw~ntage that every 

TELNET application must be modified. Therefore this 

possibility was rejected. 

. A new DNS Load Balancing Resource Record (LB) could 

defined. This record could be similar to the MX record for 

mail. There would be one record for each system. These 

records would be continuously given new preference values, 

and would always have a small TTL, preferably zero. Again, 

this choice would require modifying ewery implementation of 

TELNET, so it was rejected. 

A single CNAME RR could be used to dynamically alias HOST to 

HOSTn. This RR would always have a small TTL (zero) and 

would be changed dynamically to reflect the least loaded 

machine. For example, at first HOST1 imay be the least 

loaded, so there would be an RR "HOST 0 IN CNAME HOST1". If 

the load on HOST1 increased so that HOST2 became the least 

loaded, then this RR would be be removed and a new RR would 

be added: "HOST 0 IN CNAME HOST2". 

. A dynamically sorted list of A RRs could be used. The 

domain "HOST" could include the same A RRs as HOST1, HOST2, 

etc. These RRs would be sent with small TTLs and would be 

resorted as the load on each machine changed. 

-54-

Page 3 


The group decided that option 3 was the most preferable and 

was the easiest to implement. This brought up the issue of 

zero TTLs in the DNS. RFC 1034 is somewhat ambiguous with 

respect to zero TTLs. However, since the meeting it has 

been pointed out that RFC 1035 is not ambiguous. Zero TTLs 

mean that an RR cannot be cached, but that it can be used 

for the transaction in progress, no matter how long 

it takes to resolve. 

-55-

Dynamic Host Configuration Working Group 

Chairpersons: Ralph Droms/UMD and Phill Gross/NRI 

CHARTER 

Description 


The purpose of this working group is the investigation of 

network configuration and reconfiguration management. We 

will determine those configuration functions that can be 

automated, such as Internet address assiglnment, gateway 

discovery and resource location, and that which cannot 

(i.e., those that must be managed by network 

administrators). 

Objectives: 

0 

We will identify (in the spirit of the Gateway 

Requirements and Host Requirements RFCs) the 

information required for hosts and gateways to: 

a) Exchange Internet packets with other hosts (e.g.~ 

discover own Internet address).. 

b) Obtain packet routing information (e.g., discover 

local gateways). 

c) Access the Domain Name System (e.g., discover 

DNS server). 

d) Access other local and remote services. 

. 

o 

. 

We will summarize those mechanisms already in place for 

managing the information identified by objective I. 

We will suggest new mechanisms to manage the 

information identified by objective i. 

Having established what information and mechanisms are 

required for host operation, we will examine specific 

scenarios of dynamic host configuration and 

reconfiguration, and show how those scenarios can be 

resolved using existing or proposed management 

mechanisms. 


(to be determined) 

-57-



STATUS UPDATE 

i. Chairpersons: Ralph Droms, droms@sol.bucknell.edu and 

Phill Gross, gross@sccgate.scc.com. 

2. WG Mailing List: host-conf@rutgersoedu 

3. Last Meeting: Cocoa Beach, April 1989 

4. Next Meeting: Videoconference about June 12, or July IETF 

meeting in Palo Alto. 


6. Progress to Date (e.g., Documents Produced) 

Organizational meeting at Cocoa Beach: agreed on Charter and 

began discussion of Objective i.



CURRENT 

Reported 


by Ralph Droms and Phill Gross 

AGENDA 

a) 

b) 

ATTENDEES 

c) 

Discuss Charter 

Set date and agenda 

Mailing list 

and Objectives 

for next meeting 


Dave Borman 

David Bridgham 

Farokh Deboo 

Ralph Droms 


Bob Gilligan 

Phill Gross 

John Lekashman 

Norbert Leser 

Mark Lottor 

Louis Mamakos 

RonNatalie 

Bill Nowicki 

Drew Perkins 

Mike Petty 

Robert Reschly 

Carl~Herbert Rokitansky 

Rajeev Seth 


LanceTravis 

Bill Westfield 

MINUTES 


dab@cray.com 

’4ab@ftp.com 

..!sun!bridge2@fjd 

droms@sol.bucknell.edu 

hunaid@cray.com 

gilligan@sun.com 

gross@sccgate.scc.com 

lekash@orville.nas.nasaogov 

nl@osf.org 

mkl@sri-nic.arpa 

louie@trantor.umd.edu 

ron@rutgers.edu 

nowicki@sunocom 

ddp@andrew, cmu.edu 

petry@trantor.umd.edu 

reschly@brl.mil 

roki@dhafeu52.bitnet 

rajs%hpindbu@hp-sde.sde.hp.com 


cmt@appollo.com 

billw@cisco.com 

This meeting kicked off the Dynamic Host Configuration Working 

Group. The WG was formed to study the automatic management of 

network configuration. Phill Gross characterized the problem by 

referring to the TCP/IP protocol suite documents written by Chuck 

Hedricks. Phill pointed out the introductory document is 25 

pages long, while the management guide~is 48 pages long. What we 

hope to do in this working group is reduce the amount of hand 

configuration and "wizardry,, required to manage TCP/IP networks. 

The group began by considering the charter and a list of 

objectives. The charter and objectives met with general 

approval. The WG modified the objectives to include the writing 

of an RFC based on the results of Objective l, and/or more RFCs 

-59-

Page 2 


based on the results of Objective 3. The WG felt that the 

mechanisms to be enumerated for Objective 2 represented a simple 

rehash of information published elsewhere, and did not warrant 

the publishing of a new RFC. 

After agreeing on the charter and the objectives, the WG dove 

straight into a discussion of Objective i. We quickly decided to 

limit the scope of our discussion to "Internet participants" with 

only a single interface. ~his decision allowed us to avoid the 

"host versus gateway" and "multi-homed host ~’ religious wars... 

Next, we talked about several configuration scenarios: 

i. 

2. 

3. 

4. 

5. 

Virgin host 

Rebooted host " 

Moved host 

Replaced host 

X Window System tex~inal 

We launched this discussion with Objective I in mind - but soon 

discovered that we needed to solve the "host identification" 

problem before we could address Objective i. 

We.developed the following mode], of host identification. There 

are several data items that might be used to identify a host: 

1. Interface (hardware) address 

2. Machine identifier (e.g., serial number) 

3. IP address 

4. Domain name 

In all of the scenarios we considered, identifying a host 

involves fixing (at least) one of the above data items and then 

developing the other data items from existing or new bindings. 

The bindings may be stored in the host, stored elsewhere in the 

net or assigned dynamically. 

For example, consider replacing a user’s broken workstation. 

What remains fixed is the host’s domain name, and the remaining 

information must be found from existing bin~dings (e.g., the 

Domain Name system for IP address) or existing bindings must be 

updated (e.g., the IP to interface address in the RARP server 

must be updated). 

Administrivia: Ro~ Natalie volunteered to manage the 

host-conf@rutgers.edu mailing list. 

¯ 

-60-

Host Requirements Working Group 

Chairperson: Robert Braden/ISI 

CHARTER 

Description 


The Host Requirements Working Group has the goal of 

producing an RFC defining the official requirements for the 

software on a host which is to be part of the Interneto 


Produce a document that is the host equivalent of 

RFC-1009, "Requirements for Internet Gateways", 

providing guidance for vendors, implementors, and users 

of host software for internet applications. 

o Enumerate the protocols required, referencing the RFC"s 

and other documents describing them in detail. 

~ Provide further clarification, discussion, and guidance 

in those areas of the referenced specifications that 

contain ambiguous or incomplete information° 

e Define the current architecture as completely and 

carefully as possible, don’t invent new architecture. 

As a secondary task, provide a forum for discussing 

particular solutions to pressing host problems° 


Our objective is to publish the document early in 1989. 

-63-

Host Requirements Working Group 

Chairperson: Robert Braden/ISI 

STATUS REPORT 

i. Chairperson: Bob Braden, braden@isi.edu, (213) 822-1511 

2. WG Mailing List: let f-.hosts @NNSC. NSF. NET 

3. Last Meeting: Austin IETF, January 1989 

4. Next Meeting: Stanford IETF, July 1989 


6. Progress to date (e.g.~, documents produced): 

The document has grown to 190 pages, and a number of sets of 

very extensive comments have been considered and 

incorporated when appropriate. The decisions made at the 

last meeting have been incorporated, and some further 

changes suggested by email discussion have been made in the 

April 17 version, that will be installed as an 

Internet-Draft document. 

There are a few hard issues still to be resolved, and a 

number of areas in which further investigation would be 

desirable. Recent discussions ihave concerned the 

multihoming rules for a non-gateway host, the rules for 

addressing and source routing in SMTP, immediate vs. 

deferred processing of SMTP RCPT TO: commands, 

and IP source routing. 

The size of the document has been a cause for concern. It 

has been suggested that it would be better to split it into 

two documents, one for the application layer and support 

programs, and one for the transport layer and below. No 

decision has been taken on this. 


None 

-64-

Interconnectivity Working Group 

Chairperson: Guy Almes/Rice and Scott Brim/Cornell 

CHARTER 

Description of Working Group 

We aim to improve practical inter-autono~mous system routing 

in the Internet. 

Specific Objectives : 

Produce a practical system for Inter-Autonomous System 

routing that is (a) significantly better than the current 

system based on EGP-2 and the Stub Model, and (b) 

significantly more timely than we expect the outcome of the 

Open Routing Working Group to be. We hope to produce: 

a Mid-Term Inter-AS Routing Architecture, and 

a Border Gateway Protocol both implemented and 

deployed. 


April 1990 

-65-

Interconnectiwity Working Group 


STATUS UPDATE 

i. Chairpersons: Guy Almes, almes@rice.edu 

Scott Brim, swb@chumley.tn.cornelloedu 

2. WG Mailing List(s): IWG@rice.edu 

3. Date of Last Meeting: April, 89 at the Cocoa Beach IETF 

4. Date/Site of Next Meeting: At the sunnier IETF meeting. 


Revision 

of the draft RFCs by the summer IETF meeting. 

6. Progress to Date (e.g., documents produced): 

We have draft RFCs of both the MIRA architecture 

protocol. 

and the BGP 

Draft RFC on MIRA and draft RFC on BGP; both internal 

documents at this stage.

Interconnectivity Working Group 



Reported by Guy Almes 

AGENDA 

Morning session: Joint meeting with the Open Routing Working 

Group. Afternoon session: Closed meeting to work on problems 

raised that morning° 

ATTENDEES 

MINUTES 

Guy Almes 


Rick Boivie 

Scott Brim 

Jeffrey Burgan 

Noel Chiappa 

Joe Choy 

Mike Collins 

Dino Farinacci 

Jose Garcia-Luna 

Elise Gerich 

Tony Hain 

Jeffrey Honig 

Mike Karels 

Steve Knight 

Mike Little 

Paul Love 

Marianne Lepp 

Charles Lynn 

Matt Mathis 

Milo Medin 

Don Merritt 

Russ Mundy 

Rebecca Nitzan 

Yakov Rekhter 

Milt Roselinsky 


Dallas A. Scott 


Paul Tsuchiya 

Ross Veach 

almes@rice.edu 


rboivie@ibm.com 

swb@devvax.tn.cornell,edu 

jeff@nsipo.nasa.gov 

jnc@ics.mit.edu 

choy @ncar.ucar.edu 

collins@ccc.mfecc.llnl,gov 

dino@bridge2.3com.com 

garcia@sri.com 

epg@merit,edu 

hain@ccc.mfecc.llnl.gov 

jch@sonne.tn.cornell.edu 


knight@cray.com 

little@saic~com 

loveep@sdsosdsc.edu 

mlepp@bbn.com 

clynn@bbn.com 

mathis@faraday.ece.cmu.edu 

medin@nsipo.nasa.gov 


mundy@beast,ddn.mil 

nitzan@nmfecc.llnl.gov 

yakov@ibm.com, 

cmcvax!milt@hub.ucsb.edu 

schofield@edn-vax.dca.mil 

dscott@gateway.mitre.org 


tsuchiya@gateway.mitre.org 

rrv@uxc.cso.uiuc.edu 

The morning session was spent briefing the Open Routing Working 

Group on the Mid-Term Inter-AS Routing Architecture (MIRA) and 

the Border Gateway Protocol (BGP). Our assumptions about the 

timing of the ORWG were essentially confirmed° We presented the 

essential ideas of MIRA and BGP. 

-67-

Page 2 

Interconnectivity 

Working Group 

The afternoon session was spent going over remaining problems in 

MIRA and BGP. We spent the most time discussing the neighbor 

acquisition and neighbor reachability problems in the context of 

MIRA. A number of solutions were posed and discussed° Several 

work, but few have a reasonable combination of elegence and 

reliability.

Internet MIB Working Group 

Chairperson: Craig Partridge/BBN 

CHARTER 

Description 


As defined in RFC 1052, the original purpose was to devise 

an Internet Management Information Base (MIB) and Structure 

of the Management Information (SMI). 

Specific 

Objectives: 

After finishing version 1 of the MIB and SMI in the summer 

of 1988, the group continued meeting to discuss questions .of 

upgrading and enhancing the MIB. 


The group currently plans to release a revised Internet MIB 

sometime in 1989. 

-68-

Internet MIB Working Group 

Chairperson: Craig Partridge/BBN 

STATUS UPDATE 

i. Chairperson: Craig Partridge, craig@bbn, com 

2. WG Mailing List: mib-wg@nnsc.nsf.net~ (to joins mail to 

mib-wg--request@nnsc., ns f. net) 

3. Last Meeting: Austin, TX, January 1989 

4. Next Meeting: May 18th in Boston where it will consider a 

draft for a second version of the MIB. ~ 




none

JOMANN Working Group 

Chairperson: Susan Hares/MERIT 

CHARTER 

Description 


This "Joint Monitoring Access for Adjacent Networks focusing 

on the NSFNET Community" Working Group will: 

discuss how to.identify problems in the next hop 

network 

create a list of existing tools which can solve these 

problems (We will discuss to see if NOC-Tools Working 

Group can take over this. NSFNET will archive a list 

of these tools.) 

create a list of routing topology maps of regionals 

(possibly prepare a MAP Internet-Draft) 


See above 


6-9 months (August 31, 1989) 

-70-



STATUS UPDATE 

Chairperson: Susan Hares (Merit), skh@merit.edu 

© 

WG Mailing List: njm@merit.edu (Regional or National Net 

NOC people) 

njm-interest@meritoedu (anyone interested) 

njm-request@merit.edu 

3. Date of Last Meeting: Cocoa Beach, April 11-14, 1989 

4. Date of Next Meeting: Stanford~ July 2.5-26, 1989 

o 

Pending or New Objectives: to be detez~ined 

o 

Progress to Date (e.g., documents 

prod~[ced): 

Common SNMP monitor session 

Policies discussed; agreement on error reporting, 

outage reporting, and virus reporting 

MAPs collected 

Tools list - no progress. Possible project for NOC- 

Tools WG 

WHO SHOULD ATTEND: 

Technical representatives from mid-level or peer networks. In 

the future we may want to extend this to technical represen- 

~tatives from campus networks. However, in interest of getting a 

lot of work done quickly the initial working group will be 

limited.




(Chaired by Elise Gerich in the absence of Susan Hares) 

Reported by Elise Gerich/MERIT 

AGENDA 

Io SNMP Community Names 

2. Traffic Statistics Request 

3. ARPANET 

SNMP Community 

Names 

The discussion centered around the distribution and changing of 

the global SNMP community names. 

It was mentioned that there should be a policy for 

distribution along with the name. 

Merit asked if anyone minded changing the name° All parties, 

except for NYSERNet, did not feel strongly about the periodic 

changes of the SNMP community name. It was felt that this 

was not needed. 

A vote was taken and by majority (not unanimously), it was 

decided to not change the SNMP community name at a constant 

interval. The name will stay the Same until further notice° 

As a side note, it was mentioned that MERIT/IBM now has SNMP 

deployed in the backbone and is giving out the community name 

to any regional who wants to interoperability test. There has 

been very little interoperability testing as of the time of the 

meeting. Anyone who was interested in testing-the implementation 

was asked to talk with Elise after the meeting’. 

Mark Oros’s Questions 

There were some questions for the group posed by Mark Oros. 

These were discussed. As follows: 

How many people use SNMP/SGMP? 

Almost all of the regionals currently use it or are in the 

process of installing it. 

-72-

Page 2 

JOMANN Working 

Group 

Vendor specific 

traps: 

Mark proposed that it would be useful to have a Vendor 

Specific S~MP trap for the Proteon Gateway which would 

be used to indicate someone logging into the gateway. 

When someone successfully logged into the gateway, the 

Proteon would generate a trap. 

After some discussion, the group felt that this was a 

good idea. Proteon will be notified and it was suggested 

that all concerned parties .call tlheir friendly Proteon 

sales rep. 

Traffic Statistics Request 

Merit has asked the regionals to provide them with traffic 

statistics/data on the tralffic flowing from the regional 

into NSFNET. For example, the amount of packets/bytes 

sent from the regional to the NSS. 

Ideally Merit would like: 

Packet Size Distribution 

Distribution of traffic 

Packets 

Bytes 

If you don’t have the data,then you obviou~sly cannot provide 

it. The time-frames Merit would like to see include: 

24 hours, weekly, hourly. Raw data is also preferred. 

In summary, Merit will take whatever you have in terms of data 

collected and reports generated. 

ARPANET 

PSCNET is now the primary route to ARPANET. Much thanks 

to Matt Mathis and others for dealing with this at the 

spur of the moment. 

There is a planned NSFNET connection to ~the MILNET at univ. 

of Maryland. There is also a connection to the MILNET planned 

at NASA AMES. 

FUTURE OF JOMANN 

This topic was left up to the mailing 

discussion is planned. 

list. An E-mail 

-73-

Lan Manager Working Group 

Chairperson: Amatzia Ben-Artzi/3Com 

CHARTER 

Description 


To define the MIB (and relevant related mechanisms) needed 

to allow managementoverlap between the workgroup 

environment (LAN Manager based) and the enterprise 

environment (based on TCP/IP management). 


This translates 

into four basic areas: 

Define a set of management information out of the 

existing LAN Manager objects to allow for useful 

management from a TCP/IP based manager. 

Define extensions to the TCP/SMI when appropriate. 

Develop requirements for additional network management 

information, as needed, and work to extend the LAN 

Manager interfaces to support such information° 

Define the mechanisms of exchange of management 

information between clients and se~rers so that proxies 

can be developed. 


-74-

LAN Manager Working Group 


STATUS UPDATE 

i. Chairperson: Amatzia Ben-Artzi~ amatzia@spdo3mail.3comocom 

2. WG Mailing List: lanmanwg@spam, istc.sriocom 

3. Date of Last Meeting: Cocoa Beach April 1989 

4. Date of Next Meeting: May 1989 

5. Pending or New Objectives: to be defined 


o Draft Proposal. for MIB Objects 

o Discussed 2nd draft at the meeting 

o Working on 3rd draft. To be posted in mailing list 

this week. Hope to bring it before the "large" MIB-WG 

at their 5/18 meeting.

LAN Manager Working Group 


CURRENT 

Reported 

MEETING REPORTS 

by Amatzia Ben-Artzi 

FEBRUARY INTERIM MEETING 

The Lan Manager MIB working group met Wednesday, 2/22 in 

Sunnyvale, CA for our first meeting. The meeting was very 

productive and generated a long list of output and action 

items. Below is a summery of the meeting and major decisions 

reached. 

The minutes cover seven topics: 

I. Introduction 

2. The Group’s Objectives 

3o To Proxy or Not? 

4. Initial Documents and Editors 

5. Relationship to the MIB WG 

6. Mailing List 

7. Timetable 

Introduction 

to the Lan Manager. 

Amatzia gave a short introduction on the Lan Manager. The 

emphasis is on the management interoperability issues 

between the Lan Manager as a standard in the workgroup 

environment and the standards being developed in the 

"enterprise" environment. As both are based on the TCP/IP 

it is important that they can cooperate. Microsoft offered 

to provide a more extensive overview of the LanManager if 

people will find it useful. Please send me feedback on this 

one!! 

Group’ s Objective 

The objective of the group is to define the MIB (and 

relevant related mechanisms) needed to allow management 

overlap between the workgroup environment (Lan Manager 

based) and the enterprise environment (based on TCP/IP 

management). 

We found that it translated 

into four basic areas: 

Define a set of management information out of the 

existing Lan Manager objects to allow for useful 

management from a TCP/IP based manager. 

Define extensions to the TCP/SMI where appropriate. 

-76-

Page 2 

LAN Manager 

Working Group 

3. Proxy or Not? 

Develop requirements for additional network management 

information, as needed~ and work to extend the Lan 

Manager interfaces to support such information. 

Define the mechanisms of exchange of management 

information between clients and servers so that proxies 

can be developed. 

We concluded that the manager need to have access to the 

management information in every client in a direct way. It 

amounts to the following: 

- A client may haw~ a Management/TCP stack. 

A client may be supported by a se~er that acts as 

"proxy" on his behalf. 

The manager 

techniques 

need not be aware of which one of the 

above is being used in the workgroup. 

However, we recognized that in the proxy mode, the server 

may have two types of objects: server resident, and client 

resident. For the second type, a server-client mechanism has 

to be developed to allow the implementation of a proxy. 

4o Initial Documents and Editors 

The following documents have been identified as needed. 

Initial editors were also selected. 

- SMI Extensions: Pranati Kapadia, HP 

- MIB Objects: Jim Greuel, HP 

- NDIS Extensions (not assigned) 

- Transport APIs for NM Information access (notassigned) 

- Client-Server management protocol 

5. Relationship to the MIB group 

A real objective of this MIB group is to work under the 

"BIG" MIB group. One implication was that the MIB 

specification should follow the 1066 RFC,(specifying all 

attributes as "objects") with an appendix that actually 

describe the containment relationship (Same technique that 

was used in the CMOT RFC to re-state t~ne supported MIB) 

-77-

Page 3 

LAN Manager 

Working Group 

A big question mark is SMI. Can we live with the guideline 

of "no SMI extensions" ? We shall address it when the first 

required extension shows. We do know, however, that EVENTS 

or alerts, or alarms) are a big issue, but we where not sure 

if this was an SMI issue or what. 

We also feel very strongly that the recommendation of the 

previous MIB group should be followed: Lan Manager should be 

assigned a number of the MIB (Like TCP~ liP, or CMOT) and 

define it objects under this branch. Then, bring them 

forward to the larger group for discussion and approval. 

ONLY EXPERIMENTAL OBJECTS SHOULD BE PLACED UNDER THE 

EXPERIMENTAL BRANCH. 

The whole branch is OPTIONAL, so people who don’t implement 

it do not have to worry about conformance. It seems like we 

would want, for simplicity of conformance, at least 

initially, to say: the branch is optional, but if you 

implement it, it is ALL mandatory. The target is roughly 

20 - 30 objects initially. 

o 

Mailing list: 

Welcome a new mailing list: LanManWG@spam. istc.sri.com 

As usual, there is also a LanManWG-request. 

Initial membership: 

o 

aguilar@istc.sriocom 

jimg@hpcnd.hp.com 

-.-!ucbvax!mtxinu!excelan!ramesh 

...microsoft!henrysa 

geo@ub.com 

kapadia@hpda.hp.com 

davep@esd.3com.com 

jcham@mbunix.mitre.org 

Hunter@nmfecc.arpa 

--.!ucbvax!mtxinu!excelan!pramod 

jonab@cam.unisys.com 

kzm@twg.com 

amatzia@spd.3com.com 

Timetable 

SRI 

H-P 

Excelan 

Microsoft 

Ungerman-Bass 

H-P 

3Com 

Mitre 

Laurence Livermore Lab 

Excellan 

Unisys 

The Wollongong Group 

3Com 

March 17: First draft proposal for MIB objects in the mail. 

March 31: Comments are due back to the editor 

April 11-14: IETF meeting. We shall meet sometime there to 

discuss the proposed draft (currently planned as a half-day 

meeting) 

Thanks to all the participants for a very effective meeting. 

-78-

Page 4 

LAN Manager 

Working Group 

APRIL IETF MEETING 

ATTENDEES 

Amatzia Ben-Artzi 

Jeff Case 

Jim Greuel 

Steven Hunter 

Lee LaBarre 

Rajevv Seth 

Jim Sheridan 

Louis Steinberg 

amatzia@~spd.3+.3com.com 

case@utksxl.utk.edu 

jimg%hpcndpc@hplabs.hp.com 

hunter@ccc.mfecc.llnl.gov 


rajs%hpilndbu@hplabs.hp.com 


louiss@ilbm.com 

MINUTES 

Key actions/directions: 

Group agreed that lanman-mib should be part of the standard 

mib version 2. 

Events will be introduced on a limited basis and enter as 

"experimental" to "the MIB. 

Experimental events should have examples in the standard how 

they fit into CMOT and SNMP. 

The event "thresholds" (i.e., boundery conditions) should 

defined as standard objects using the standard SMI (RFC 

1065). They will, however, be defined in tables to preserve 

their internal dependency/relation. 

Next activities: 

Review 3rd draft over the mailing list. 

Present to MIB-WG at 5/18. 

Next meeting to finalize the RFC or start the next phase 

[depending on progress with the MIB-WG] at IETF meeting in 

July. 

-79-

-82-

NISI Working Group 

Chairpersons: Karen Bowers/NRI and Phill Gross/NRI 

CHARTER 

Description 


The NISI WG will explore the requirements for common, shared 

internet-wide network information services. The goal is to 

develop an understanding for what is required to implement 

an information services "infrastructure" for the Internet. 

This effort will be a sub-group of the User Services WG and 

will coordinate closely with other IAB and FRICC efforts in 

the area of Directory Services. ~ 

Specific Obj ectives : 

1) Write a short white paper to serve as a starting point 

for discussions on an Internet-wide information 

services infrastructure. 

2) Develop a more detailed statement of required 

information services as currently supplied by a typical 

network information service organization. This will 

initially take the form of an annotated outline of 

services, suitable to be expanded into a full 

Requirements Document. 

3) Define candidate pilot projects for consideration by 

this or other groups to implement. Initial candidates 

include: 

- Define common user interface for information 

retrieval by electronic mail. 

- Define common user interfaces for other information 

services (e.g., white pages) 

- Define the minimally required infoz~ation content 

for an Internet-wide use registration database and 

begin to collect such information. 


Objective 1 -- Draft to be distributed by email to the 

USWG mailing list by June 30, 1989. 

Objective 2 -- Annotated outline, ready for volunteer 

writing assignments, to be distributed by email to the 

USWG and the NISI mailing lists by June 30, 1989 

Objective 

3 -- To be determined


Chairpersons: Karen Bowers/NRI and ]?hill Gross/NRI 

STATUS UPDATE 

I® Chairpersons: Karen ]3. Bowers / bowers@sccgate.scc.com 

Phill Gross / gross@sccgate.scc.com 

2. WG mailing list: NISItMERI...EDU 

3. Date of Last Meeting: 04 May 89 / NRI 

o Date of Next Meeting: 25-28 Jul 89 / Stanford IETF ~ 

¯ 

Pending Objectives: 

Two Immediate Actions: Network Information Services 

Requirements Document 

White Paper: Network Information 

Services Infrastructure (NISI) 

Both drafts to be distributed prior to the July IETF 

Meeting. These drafts will be further expanded/edited by 

the NISI WG and then presented to the full body of the USWG 

for review. 


First Meeting 

Held 

-85-


Chairpersons: Karen Bowers/NRI and Phill Gross/NRI 


Reported by Karen Bowers and Phill Gross 

AGENDA 

- Individual Information Services Briefings 

* NSFnet, NIS (MERIT) - Jim Sweeton 

* NSFnet, NNSC (BBN) - Craig Partridge 

* CSNET, CIC (UCAR) - Laura Breeden 

* BITNET, BITNIC (EDUCOM/BITNET) Ji m Co nklin 

* DDN, NIC (SRI) - Mary Stahl 

* PREPnet (PA Research and Economic Partnership) 

Thomas Bajzek 

- Strategy for Preparation of the Network Information 

Services Requirements Document : purpose of document, 

how best to prepare 

- Discuss Related Projects: IAB White Pages Workshop 

FRICC DECNET/Internet Directory 

Services (Phill Gross) 

- Discuss/Modify Strawman Agenda: 

* Pilot Project Selection 

* Technical Approach to be Employed 

Explore Methods for Providing Selected Services 

Define Support Requirements 

Define the Common, Shared User-Interface 

Define Applications to Interface Current Internet 

Services 

* Follow-on Activities 

How to Implement 

Issues for an Internet-wide Information Services 

Infrastructure (NISI) 

- Determine Critical Actions to be Undertaken Immediately 

by the NISI WG 

ATTENDEES:.. Thomas Bajzek (PREPNET), Karen L. Bowers (NRI), 

Laura Breeden (CSNET), Jim Conklin (BITNET), Jose Garcia-Luna 

(DDN/SRI), Phill Gross (NRI), Craig Partridge (NNSC/BBN) 

Mike Roberts (EDUCOM), Mary Stahl (DDN/SRI), Jim Sweeton 

(NSI/MERIT). Participants unable to attend this session but 

who have been invited to join this closed forum are: 

Waverly Williams (SPAN) and Karen Roubicek (NNSC/BBN) 

(FARNET representation was provided by both Laura Breeden and 

Thomas Bajzek. Guy Almes was unable to attend.) 

-86-

Page 2 

NISI Working 

Group 

MINUTES 

The Network Information Services Infrastructure (NISI) 

held its first meeting on May 4, 1989, 12:00pm - 5:45pm 

at the Corporation for National Research Initiatives, 

Reston, VA. 

The goal of this meeting was to explore the technical and nontechnical 

issues of providing common, shared Internet-wide 

information services. 

As a basis for understanding the current, general information 

services requirements of t]~e Internet community, each attendee 

who currently is responsible for providing network information 

services was asked to provide a short presentation summarizing 

the type and guality of services they provide, and the services 

they see a need for but currently do not provide. This exercise 

enabled the WG to develop a baseline of what types of services 

exist, overlap and differ, how those services are implemented, 

and the value-added services for which there could be a future 

demand. This information will be assembled into a "Network 

Information Services Requirements Document" by the NISI WG and 

presented to the body of the USWG for review and comment. 

Phill Gross provided an update on the results of Dave Clark’s 

Workshop on Internet White Pages. Last week a draft Plan for 

Internet Directory Services was released by Karen Sollins to 

all the workshop participants for comment/review. It is purported 

this document will be released shortly to the public, at which 

time it will be available to the NISI WG. In summary, X.500 was 

identified as the most likely candidate for directory service. 

However, the consensus of the workshop is to propose a field 

trial(s).to include experiments with at least an X.500 

implementation, Profile to explore a non-hierarchical structure 

and possibly DECnet’s Network Architecture Naming Service 

(DNANS). Another related directory services project 

underway is the current indepth examination of DECnet’s 

Network Architecture Naming Service (DNANS) by the FRICC, 

anticipation of implementing this service in the large scale 

DECnet Internet. This will be an important issue in the 

upcoming transition from DECnet Phase IV to DECnet Phase V. 

A discussion of the short and mid-term agenda for the NISI 

WG ensued. The WG members decided on two immediate actions: 

i) to write a Network Information Services Requirements Document 

that identifies information sez~ices currently available, 

those that overlap and differ, value-added services that are 

or should be made available, and how these services are 

currently implemented. In addition, this document could 

include "lessons learned" on how to better provide these 

services.

Page 3 


2) to prepare a white paper defining the concept of a Network 

Information Services Infrastructure, to be made available as a 

reference document for any organization proposing/developing a 

new or follow on network information service or network 

information service infrastructure effort. 

Actions for follow-on meetings include: 

Explore the preliminary steps in developing a Common User 

Interface(s) for email information services and for white 

pages and determine if these are pilot projects the USWG 

should undertake. Perhaps at a. minimum, the NISI WG could 

"define" what those Common User Interfaces should be. 

Examine the requirements for and issues associated with 

common/standard User Registration Database Attributes and 

accomplish a draft definition of those attributes. An 

associated task would be to define tools for database 

management as well. 

Coordinate with the FRICC/IAB on our mutual concerns and 

related activities. 

The next meeting will be in Stanford, 25-28 July 1989. 

In the interim, initial drafts of the NIS Re~lirements Document 

and the NISI white paper will be prepared by Phill Gross 

and Karen Bowers and provided by email to the NISI WG members 

for their reciprocal input prior to the July IETF meeting. 

-88-

Network Management Services Interface Working Group 

Chairpersons: Jeff Case/UTK and Keith McCloghrie/TWG 

CHARTER 

Description 


The objective of the Network Management Services Interface 

Working Group is to define a management services interface 

by which network management applications may obtain access 

to a heterogeneous, multi-vendor, multi-proto~ol set of 

network manageable devices. While such an interface is 

desirable, the extent to which an implementation is feasible 

in real systems, is not clear. 

The services interface is intended to support the network 

management protocols and strategies commonly found in 

networking devices today. As this is an Internet 

Engineering Task Force Working Group, the natural focus is 

on current and future network management strategies used in 

the Internet. However, the interface being defined is 

expected to be sufficiently flexible and extensible to also 

allow support for other protocols, at little or no extra 

cost. The anticipated list of supported strategies and 

protocols includes: the standard TCP/IP network management 

protocol, i.e., the Simple Network ManagementProtocol 

(SNMP); the standard OSI network management protocol, i.e., 

the Common Management Information Protocol (CMIP) ; 

experimental TCP/IP network management protocol, i.e., 

Common Management Information Protocol over TCP/IP (CMOT); 

the Manufacturing Automation Protocol and Technical Office 

Protocol (MAP/TOP); as well as proprietary network 

management protocols. 


l) 

2) 

3) 

~) 

define an architectural framework for such a service 

interface, 

advance an RFC which describes the interface, 

implement one or more prototypes~ and 

evaluate the viability of the interface including 

recommendations for future work and the feasibility of 

implementation in real systems° 


Not known at this time 

-90-


Chairperson: Jeff Case/UTK and Keith McCloghrie/TWG 

STATUS UPDATE 

1 o Chairpersons : Jeff Case, case@UTKUXl. UTK. EDU 

Keith McCloghrie, kzm@TWGo COM 

2. WG Mailing List(s): none implemented at this time 

3. Date of Last Meeting: Cocoa Beach, FL April ii, 1989 

4. Date of Next Meeting: 

May 15-17, 1989 in conjunction with the Boston IFIPS 

conference 

(Editor’s note: this meeting will be postponed because 

expected contributions have. not been received as expected. ) 

¯ 

Pending 

or New Objectives: 

No changes in objectives resulted from this meeting. 

0 


o Initial meeting held. We are working through the 

process. Revisons to the initial draft document are 

underway. 

o There is a draft document which was discussed in the 

meeting. Revisions to the draft are underway. 

-91-


Chairpersons: Jeff Case/UTK and Keith McCloghrie/TWG 

CURRENT MEETING REPORT: 

Reported by Jeff Case and Keith McCloghrie 

AGENDA 

Ist Meeting 

Introductions, registration, etc (15 min) KZM 

Introduction to the problem and work in progress (45 min) JDC 

Discussion of the draft RFC (60 min) JDC 

Brainstorm about architecture required (45 min) KZM 

Organizational details: mtgs, mailing list, etc. (30 min) KZM 

ATTENDEES 

Momhammad Alaghebandan 

Cathy Aronson 

David Bridgham 

Jeff Case 

John Chao 

Danny Cohen 

John Cook 


Lionel Geretz 

Jim Greuel 

Brian Handspicker 

Steven Hunter 

MarkKepke 

Lee LaBarre 

Norbert Leser 

Paul Love 


Bill Norton 

Rajeev Seth 

Jim Sheridan 

Lance Travis 



mra@bridge2.3com.com 

cja@merit.edu 

dab@ftp.com 

case@utkuxloutk.edu 

jchao@bbn.com 

cohen@isi.edu 




jimg%hpcndpc@hplabs.hp.com 

bd@vines.dec.com 

hunter@ccc.mfecc.llnl.gov 

mak%hpcndm@hplabs.hp.com 


nl@osf.org 

loveep@sds.sdsc.edu 

kzm@twg.com 

wbn@merit.edu 

rajs%hpindbu@hp-sdeosde.hp.com 


cmt@apollo.com 

sw01@andrew.cmuoedu 


MINUTES 

An initial meeting of the Working group was held on April ii at 

the Cocoa Beach IETF meeting. Jeff Case presented the problem 

and explained the work that had taken place before the meeting. 

A draft document was distributed and discussed. Several 

individual volunteered to prepare and forward alternate text for 

sections of the document before May 1 so that a new draft can be 

prepared and distributed before the next meeting. It was agreed 

to attempt to meet in Boston sometime between May 15-17 in 

conjunction with the IFIPS network management conference and the 

MIB working group meeting. (Editor’s note: however, since 

expected contributions to the draft document have not 

materialized in a timely fashion, this meeting will be 

postponed.) 

-92-

NOC-Tools Working Group 

Chairperson: Robert Enger/Contel 

CHARTER 

Description 


The NOC-Tools Working Group will develop a catalog to assist 

network managers in the selection and acquisition of 

diagnostic and analytic tools for TCP/IP Internets. 


Identify tools available to assist network managers in 

debugging and maintaining their networks. 

o 

o 

o 

o 

Publish a reference document listing what tools are 

available, what they do, and where they can be 

obtained. 

Arrange for the central (or multi-point) archiving 

these tools in order to increase their availability. 

Establish procedures to ensure the ongoing maintenance 

of the reference and the archive, and identify an 

organization willing to do it. 

Identify the need for new or improved tools as may 

become apparent during the compilation of the reference 

document. 


The first edition of the catalog will be submitted for final 

review at the October-November IETF meeting. Preliminary 

versions will be made available earlier. 

-94-

NOC- Tools Working Group 


STATUS UPDATE 

Io Chairperson: Robert Enger, enger@sccgate.sccocom 

2. WG Mailing List: noc~ools@merit.edu 

3. Date of Last Meeting: Cocoa Beach, April 12, 1989 

4. Date of Next Meeting: Stanford, July 25-28 1989 

5. Pending or New Objectives: Final review of the catalog 

planned, for Octobe]~November IETF Meeting. 


Preliminary catalog outling and entry format have been 

developed. First pass made at enumerating the t°ools 

available.




Reported by Robert Enger 

ATTENDEES 

MINUTES 

Mohammad Alaghebandan 

Cathy Aronson 

Jeff Case 

John Chao 

John Cook 

Robert Enger 


Mark Fedor 

Steven Hunter 

Gary Malkin 

Don Morris 

Bill Norton 

Joel Replogle 

Joyce Reynolds 

Karen Roubicek 

John Scott 

Rajeev Seth 

Jim Sheridan 

Mary Stahl 

Bob Stine 




mra@bridge2.3com.com 

cja@merit.edu 

case@utkuxl.utk.edu 

jcha@bbn.com 


enger@sccgate.scc~com 


fedor@nisc.nyser.net 

hunter@ccc.mfecc.llnlogov 

gmalkin@proteon.com 

morris@ncar.ucar.edu 

wbn@meritoedu 

jr@ncsa.uiuc.edu 

jkrey@venera.isi.edu 

roubicek@nnsc.nsfonet 


rajsohplndbu@hp-sde.sde.hp.com 


stahl@sri-nic.arpa 

quest@edn-unix.dcaomil 

sw01@andrew, cmuoedu 



The kick-off meeting was quite productive, and was a good start 

to meeting our group’s goal of producing a document and 

disbanding by December of this year. 

We began the meeting by reviewing the charter of the Noctools 

Working Group. Briefly, the purpose of the Noctools Working 

Group is to produce the first edition of a catalog of network 

management tools for TCP/IP inte;nets, and to identify one or 

more sites to serve as tool and catalog repositories. 

Incredibly, we have already received volunteers for catalog and 

tool repositories: Phil Almquist, of Stanford, and Mark Fedor, of 

Nysernet, each volunteered his own site. 

We then discussed the proposed structure of the tool catalog. 

The bulk of the document will be an alphabetic list of network 

management tools. The list of entries will be preceded by an 

intro describing the catlog’s purpose and structure, and an index 

into the catlog. The index will group tools according to 

function or category; some tools will be listed in several 

functional groups. Developing a workable taxonomy is important 

-96-

Page 2 


for indexing the tool catalog. Our goal is to allow the 

document’s readers to quickly locate the tools that will meet 

their needs. 

The need for a useful index was the motivation for a discussion 

on a taxonomy of network management tools. There was little 

consensus, other than that the "IEEE Five" (performance, fault, 

configuration, accounting, and security management) do not 

constitute a very useful taxonomy. From floor came the sound. 

point that attempting to categorize at this stage is premature; 

we need to examine our data before attemptilng-to describe them. 

We decided to defer the development of a taxonomy until we had 

the opportunity to review some number of entries. 

We also discussed the scope of the catalog. In summary, even 

though we are cataloging tools for internet management, some LAN 

management tools and tools that run only under certain operating 

systems or hardware configurations are potentially eligible for 

inclusion in the catalog. We did not, nor do we need to, develop 

criteria for differentiating internet management tools from other 

management tools. There was~ however, consensus that breakout 

boxes will not be included in the catalog. 

As a basis for discussion, we developed a quick list of internet 

tools that probably will be included[: 

arp 

ding 

etherfind 

internet rover 

lan analyzer 

mconnect 

netspy 

netspy 

netwatch 

nnstat 

nslookup 

nysernet snmp tools 

overview 

ping(s) 

sniffer 

tcpdump 

tcptrace 

tokenview 

xnetmon 

xup 

After enumerating the tools, we then discussed the scope and 

format of individual tool descriptions. To avoid unfairness to 

products and legal battles with their vendors, descriptions will 

-97-

Page 3 


be strictly objective. We agreed on a working format for the 

tool entries; each entry will have the following sections, with 

no more than a few paragraphs for each: 

¯ 

¯ 

¯ 

¯ 

i0. 

Tool name. 

Key word list: for now, a best guess. We will have a 

uniform key-word list in the final catalog. 

Abstract: a brief description of the tool’s purpose and 

characteristics. 

Mechanism: how the tool works. 

Caveats: cautions about tool impact on system performance, 

etc. " 

Hardware requirements. 

Software requirements. 

Related analysis tools: post processors, data reduction 

tools, etc. 

~vailability/Support: How to obtain the tool, and whether 

is public domain, copyrighted, or commercially available. 

it 

This will NOT include pricing information. 

Bugs/limitations. 

The issue of accepting vendor inputs for the catlog came up. Our 

consensus was that we will welcome vendor submissions, though the 

Noctools Working Group will retain editorial control over the 

catalog. 

>From the floor came the excellent suggestion to establish a 

review panel. This would provide some anonymity to reviewers, 

and could insulate them from vendor pressure. 

Towards the meeting’s end, we solicited volunteers to write draft 

entries for the tools we had listed. For now, entries will be 

submitted in ASCII, to the mailing list. As entries are 

collected, the draft of the tool catalog will reside in the ietf 

drafts directory. 

In other business, co-chairmen Bob Stine and Bob Enger were 

tasked to develop a tool-use survey and forward it to NOCs, 

mailing lists, trade magazines, and a few of the internet old 

boys. Phill Gross was tasked to inform Jon Postel of our group’s 

activities. 

A mailing list, noctools@merit.edu, has been established for the 

working group. As usual, requests to join the list should be 

directed to noctools-request@merit.edu. 

-98-

-i00-

Open SPF-based IGP Working Group 

Chairpersons: Mike Petry/UMD and John Moy/Proteon 

CHARTER 

Description 


The 0SPF working group will develop and field test an 

SPF-based Internal Gateway Protocol. The specification will 

be published and written in such a way so as to encourage 

muliple vendor implementations. 


lo Design the routing protocol, and write its 

specification. 

¯ Develop multiple implementations, and test against each 

other. 

3. Obtain performance data for the protocol. 

4. Make changes to the specification (if necessary) and 

publish the protocol as an RFCo 


We have a complete protocol specification. Implementation 

experience and performance data should be obtained during 

the summer of 1989. The specification should be ready for 

final review by the October-November IETIFo 

-102-


Chairpersons: Mike Petry/~/MD and John Moy/Proteon 

STATUS UPDATE 

I. Chairpersons: Mike Petry, petry@trantor.umdoedu 

John Moy, jmoy@proteon.com 

2 

WG Mailing List(s): 

ospfigp@trantor.umd.edu 

o 

Date of Last Meeting: 

April 1989, Cocoa Beach, FL 

¯ 

¯ 

Date of Next Meeting: Teleconference scheduled tentatively 

for the beginning of June 


o New revision of specification to be submitted (5/89) 

o Testing of implementations (summer 89) 

o Final specification to be submitted (fall 89) 

¯ 


o The OSPF Specification, first revision (1/89) 

o First revision of the OSPF specification finished 

(1/89) 

o Two OSPF implementations nearing completion 

o OSPF presentation given during IETF plenary (4/89) 

-103-


Chairpersons: Mike Petry/UMD and John Moy/Proteon 

CURRENT 

Reported 


by John Moy 

AGENDA 

The OSPFIGP working group met for a half day on April llth 

in Cocoa Beach. 

ATTENDEES 

MINUTES 

-~effrey Burgan 

.~-Rob Coltun 

,Dino Farinacci 

~Elise Gerich 

Jeffrey Honig 

Van Jacobson 

Steve Knight 

Mike Little 

Milo Medin 

John Moy 

Mike Petry 

Robert J. Reschly 

Paul Tsuchiya 

Ross Veach 

jeff@nsipo.nasa.gov 

rcoltun@trantor.umd.edu 


epg@merit.edu 

jchesonneotn.cornell.edu 

van@helio.ee.lblogov 

knight@baldmt.crayocom 

little@saic.com 

medin@nsipo.nasa.gov 

jmoy@proteo~.com 

petry@trantor.umd.edu 

reschly@brl.mil 

tsuchiya@gateway.mitreoorg 

rrv@uxc.cso.uiucoedu 

It was decided to shorten the name of the protocol, and the 

name of the working group, from OSPFIGP to OSPF. 

¯ 

¯ 

¯ 

We talked for a while about variable lenqth subnet masks. 

The present OSPF specification attempts ~:¢) specify a minimum 

number of rules so that the set of subnet masks for any IP 

network is consistent. It was widely viewed that these 

rules, and their attendant explanation, were inadequate. 

Much more text is needed to explain valid methods for 

assigning subnet masks. It was agreed that this kind of 

discussion is outside the scope of the routing protocol, and 

so should be moved to a separate document. 

The subject of authentication came up. OSPF has a 16-bit 

authentication type field, and a 64-bit field that can be 

used for things like encrypted checksums, in its standard 

packet header. Jeff Schiller explained his new proposal for 

an authentication IP option. This may alleviate the need 

for authentication support in the OSPF header. However, for 

the moment we decided to keep the authentication support 

unchanged. 

We previewed the presentation that was presented to the IETF 

-104-

Page 2 


¯ The following changes to the OSPF specification were agreed 

upon. Small changes have been omitted. For more details, 

see the next draft of the OSPF specification. 

a¯ 

Do 

co 

The [)-bit was removed from the summary links 

advertisement. Router IDs now must be distinguishable 

from class A, B, and C network numbers. 

IP interface addresses are now specified in a router’s 

router links advertisement. 

Cost of links to transit nodes must be > 0. 

Receiving a Database Description packet with the INIT 

bit set always resets the adjacency. 

The DR calculation procedure was modified slightly. ~ 

A DR priority of 0 means that the router is ineligible 

to become DR. 

OSPF routing packets will have their IP precedence set 

to "Internetwork Control". 

A network mask has been added to the summary links 

advertisement. 

® There was discussion of the LS°checksum field which resides 

in the link state advertisement header~ This currently 

specifies the Fletcher (ISO) checksum. We could not find any 

reason why this checksum is stronger than the IP checksum, 

and it is harder to calculate. A decision to change to the 

IP checksum is pending. Van Jacobson offered references 

comparing the two checksums. In any case, the calculation of 

the LS checksum field is not optional¯ 0 will be an illegal 

value, regardless of which~checksum is used. 

¯ The two current OSPF implementations reported their 

progress. John Moy’s implementation is written and is in the 

debugging stage. Rob Coltun has made similar progress. The 

two implementations have not yet attempted to talk to each 

other. Performance data is expected at the next IETF. 

-105-

Open Systems Routing Working Group 

Chairperson: Marianne Lepp/BBN 

CHARTER 

Description 


The Open Systems Routing Working Group is chartered to 

develop a policy-based AS-AS routing protocol that will 

accommodate size and general topology° 

Specific 

Objectives: 

Architecture 

Functional Specification 

Draft Protocol Specification 


December 1989 

-106-

Open Systems Routing Working Group 

Chairperson: Marianne Lepp/BBN 

STATUS UPDATE 

I. Chairperson: Marianne Lepp, mlepp@bbn.com 

2. WG Mailing List: open-rout-interest 

3. Last meeting: teleconference at BBN and ISI March 23, 1989 

4. Next Meeting: late May~ to be announced 


6. Progress to date (e.g., Documents Produced): 

o IDEA 007 Requirements 

o Functional Specification 

o Architecture in draft 

CURRENT MEETING 

REPORT 

none 

-107-

OSI Interoperability Working Group 

Chairpersons: Ross CalIon/DEC and Robert Hagens/Univ of Wisc 

CHARTER 

Description 


Help facilitate the incorporation of the OSI protocol suite 

into the Internet, to operate in parallel: with the TCP/IP 

protocol suite. Facilitate the co-existence and 

interoperability of the TCP/IP and OSI protocol suites. 


The following are specific short-term goals and objectives 

for the OSI WG. Other mid-term objectives have also been 

identified and are available from the chairs. 

Specify an addressing format (from those available from 

the OSI NSAP addressing structure) for use in the 

Internet. Coordinate addressing format with GOSIP 

version 2 and possibly other groups. 

Review the OSI protocol mechanisms proposed for the 

upcoming Berkeley release 4.4. Coordinate efforts with 

Berkeley folks. 

Review GOSIP. Open liaison with Government OSI Users 

Group (GOSIUG) for feedback of issues and concerns that 

we may discover. 

What routing should be used short term for (i) 

intra-domain routing; and (ii) inter-domain routing? 

For interoperability between OSI end systems and TCP/IP 

end systems, there will need to be application layer 

gateways. Are there outstanding issues remaining here? 

Review short term issues involved in adding OSI 

gateways to the Internet. Preferably, this should 

allow OSI and/or dual gateways to be present by the 

time that Berkeley release 4.4 comes out. 


Still being determined 

-108-


Chairpersons: Ross Callon/DEC and Robert Hagens/Univ of Wisc 

STATUS UPDATE 

I® Chairperson’s: Ross Callon (DEC) callon@erlang.dec.com 

Rob Hagens (UWisc) hagens@cs.wisc.edu 

o 

WG Mailing List(s) 

ietf-osi@cs.wisc.edu - submissions to list 

ietf-osi-request@cs, wisc. edu - . addition/deletions 

3. ’Date of Last Meeting: Cocoa Beach, April 11-14, 1989 

e 

Date of Next Meeting: Stanford, July 1989 

o 

Pending or New Objectives : 

Write RFC for CLNP Echo. (draft by the next meeting) 

Propose mechanism for encapsulation~routing~network 

management of CLNP inside DoD IP for production purposes. 

(very rough draft of issues by the next meeting) 

Prepare the IETF-OSI "OSI documents to read" list. (ongoing) 

Prepare IETF-OSI comments on Gosip V2. (at the next meeting) 


o RFC 1069 and 1070 

We have made significant progress toward aligning the 

proposed Internet NSAP address format (from RFC 1069) 

with the Gosip NSAP address format, version 2. 

We have started definition of an echo-request/ 

echo-reply function to propose as an RFC and possibly 

as an addendum to ISO 8473. 

7. Documents Produced: RFC 1.069, 1070 

-109-


¯ 

Chairpersons: Ross CalIon/DEC and Rob Hagens/Univ of Wisc 

CURRENT 

Reported 


by Ross Callon and Rob Hagens 

AGENDA 

Morning 

io 

Status: 

- Gosip, version 2 

- Berkeley 4.4 release 

2. Echo function for CLNP (ISO 8473) 

3. Alignment of OSI NSAP address proposals 

- RFC 1069 

- New proposal from NIST 

- New proposal from Boeing 

Afternoon 

© 

Discussion: 

when do we really need OSI in the Internet? 

~ 

Discussion: proposed interoperability strategies 

0 

Tentative 

plans for future WG meetings 

ATTENDEES 

David Borman 

Ross Callon 

Mike Collins 

Jerry Cronin 

Farokh Deboo 

Dino Farinacci 

Lionel Geretz 

Martin Gross 

Rob Hagens 

Tony Hain 

Bob Harris 

Gary Malkin 


Don Merritt 

Russ Mundy 

Zbigniew Opalka 

Rex Pugh 

Yakov Rekhter 

Carl-herbert Rokitansky 

Milt Roselinsky 

Dallas A. Scott 

Jim Sheridan 

Lance Travis 

Rick Wilder 

dab@cray.com 


collins@cccomfecc.llnl.gov 

1842eeg-intg2@afcc-oal.arpa 

..!sun!bridge2!fjd 



martin@protolaba.dca.mil 

hagens@cs.wisc.edu 

haun@ccc.mfecc.llnl.gov 

harris@sparta.com 

gmalkin@proteon.com 

kzm@twg.com 


mundy@beast.ddn.mil 

zopalka@bbn.com 

pugh%hprnd@hplabs.hp.com 

yakov@ibm.com 

roki@dhafeu52 bitnet 

cmcvax!milt@hub.ucsb.edu 

dscott@gateway.mitre.org 


cmt@apollo.com 

rick@gateway.mitre.org 

-ii0-

Page 2 


MINUTES 

The meeting was convened by co-chail~nen Ross Callon and Rob 

Hagens. An attendance list will be published with the Proceedings 

of the IETF. The major issues discussed at this meeting included: 

status reports on 4.4 BSD and GOSIP Version 2, an Echo function 

for CLNP, a tilmetable for needed OSI functionality in the 

Internet, and alignment of the NSAP address proposals. 

Brief status reports on 4.4 BSD and GOSIP Version 2 were given by 

Rob Hagens. 

4.4 BSD 

TP4/CLNP runs over software loopback. 

Next step will be testing with EON 

GOSIP Version 2 

A draft for public comment will be released 

90 day comment period. 

in early May. 

ECHO Function for CLNP 

Rob Hagens presented his proposal for an Ecl~o function for CLNP. 

The proposal was discussed and several changes to the proposal 

were recommended by the working group. An outline of the 

proposal along with the recommended changes is included below. 

Mechanics 

Echo and Echo Reply must be processed in the same manner as a DT 

PDU. EC and ECR PDUs are identical to the DT PDUs with the 

following exceptions: I) type field EC IE, ECR IF. 2) 

segmentation part is always present. 3) the E/R flag is 

optional. 

The E/R flag being optional was one of the changes recommended by 

the working group. The original proposal stated that the E/R flag 

never be set. 

Receiving EC 

EC processed like DT. 

EC given to Echo entity 

Echo entity issues an ECR with: 

¯ 

source and destination addresses reversed 

TTL set to the normal value that the system uses when 

generating a DT 

EC PDU included as data parameter of ECR 

ER flag optionally set on ECR. 

A note will be added stating that the E/R flag can be optionally 

set, but the usefulness of the ER pdu will depend upon the 

ability of the receiving system to process it. 

-ill -

Page 3 


PDU Options 

All options in EC are copied in ECR. 

RR option is copied but initialized 

into the ECR data parameter. 

since the EC RR is copied 

The setting of the priority option was discussed and it was 

decided that it should not always be set to a default value of 0. 

Source Routing 

The group discussed whether source.routing could be used as a 

substitution to the proposed echo function. Tihe idea would be 

that to simulate echo, one could source route a packet through a 

remote peer and back to the originator. The first problem with 

source routing is that it has a bug in its specification whereby 

it will only work if all intermediate systems along the path 

implement source routing. The second problem is that the use of 

the source routing option will change the packet processing, 

thereby failing to meet the goal of treating echo packets as much 

as possible like normal data packets. In addition, it was 

pointed out that the number of source route entries is limited 

due to the PDU header size. In principle, it may not be possible 

to ping any system given the limited number of source route 

entries. 

In addition, 

automatically 

ECR pdus will never have a source route 

generated. 

When is OSI needed in the INTERNET? 

The group discussed this issue which has been a repeated topic in 

several network forums. The group developed a timetable of when 

OSI functionality should be available on the internet. 

t0: 4.4 BSD is released (beta). 

cI/~S subnets (isolated). 

Encapsulation between isolated subnets by using smart gateways 

with fixed tables. 

tl: 4.4 BSD is released. 

t2: Intra Domain IS-IS Routing (Vendor’s release). 

Inter Domain IS-IS Routing (Static Tables). 

Intra Domain IS-IS reaches DP status. 

ALIGNMENT OF NSAP ADDRESS PROPOSALS 

Ross Callon led the discussion of the three NSAP address 

proposals. The three proposals are outlined below. 

RFC 1069 

Goal 

Consistent with ISO NSAP, ANSI/ISO Intra Domain Routing, Other 

-112-

Page 4 

OSI Interoperability 

Intra Domain Routing, 

Flexibility. 

Working Group 

and Future Inter Domain Routing. 

Long Term Growth. 

Result 

Use ICD value assigned to DoD. 

Specify high order fields. 

Flexible ’IGP Specific’ part. 

Selector. 

Pad to 20 octets. 

Two IGP Specific formats specified; DoD, and ANSl/OSI. 

Problems 

Divergence (GOSIP and ANSI). 

Too much flexibility (multiple IGP Specific Formats)° 

NIST PROPOSAL 

Basically RFC 1069 with the following changes: 

Expanded Global Area to 3 octets and renamed the field 

’ADMIN AUTHORITY’ (was 2 octets in RFC 1069). 

Specifies one IGP Specific Format that is ANSI consistent 

(last 9 octets consistent with intra domain routing). 

padding was moved. 

BOEING PROPOSAL 

AFI specifies ISO DCC for the IDI. 

ie. for the US AFI DCC IDI 

39 84 OF 

Not padded to 20 Octets 

ORG ID 5 bytes 

The working group discussed the Boeing proposal and realizes 

there should be more fields to meet ihierarchical needs but the 5 

byte ORG ID is excessive, therfore the group concluded that the 

proposal is not appropriate~ 

It was decided that the differences between the RFC 1069 and the 

NIST PROPOSAL would be resolved in the following manner: 

i) Rewrite RFC 1069 with G].obal Area expanded to 3 octets and 

specifying one IGP Specific Format. 

Suggest that NIST change their proposal so that the reserved 

section matches our padding (after routing domain). 

This work should be completed 

by the next IETF. 

AGENDA FOR NEXT IETF 

The agenda for the next IETF was proposed as follows: one half 

day each for presentations and discussions on (i) Directory 

Services; (ii) Intra Domain Routing; (iii) Inter Domain Routing; 

and (iv) comments on Gosip version 

-113-

-114-

PDN ROUTING WORKING GROUP 

Chairperson: Carl-Herbert Rokitansky/Fern University of Hagen 

CHARTER 

Description 


The DoD INTERNET TCP/IP protocol suite has developed into de 

facto industry standard for heterogenous packet switching 

computer networks. In the US, several hundreds of INTERNET 

networks are connected together; however the situation is 

completely different in Europe: The only network which could be 

used as a backbone to allow interoperation between the manly 

local area networks in Europe, now subscribing to the DoD 

INTERNET TCP/IP protocol suite, would be the system of Public 

Data Networks (PDN). However, so far, no algorithms were 

provided to dynamically route INTERNET d~tagrams through Xo25 

public data networks. Therefore the goals of the Public Data 

Network Routing working group are the development, definition 

and specification of required routing and gateway algorithms for 

an improved routing of INTERNET datagrams through the system 

of X.25 Public Data Networks (PDN) to allow worldwide 

interoperation between TCP/IP networks in various countries. In 

addition, the application and/or modification of the developed 

algorithms to interconnect local TCP/IP networks via ISDN 

(Integrated Services Digital Network) will be considered. 

Specific Objectives and Estimated Timeframe for Completion: 

Application of the INTERNET Cluster Addressing Scheme to 

Public Data Networks. (Already done, see produced 

documents) 

Development of hierarchical VAN-gateway algorithms for 

worldwide INTERNET network reachability information 

exchange between VAN,gateways (Already done, see produced 

documents) 

Assignment of INTERNET/PDN-cluster network numbers to 

national public data networks. (Mapping between INTERNET 

network numbers and X.121 Data Network Identification Codes 

(DNICs) (almost done, RFC-Draft) 

Assignment of INTERNET/PDN-cluster addresses to PDN-hosts 

and VAN-gateways according to the developed hierarchical 

VAN-gateway algorithms (RFC-Draft, will be completed by 

July ’89) 

5) Definition of the PDN-cluster addressing scheme as an 

Internet standard (to be written up as an RFC-Draft by Fall 

’89) 

Specification of an X.121 Address resolution protocol 

(RFC-Draft, expected to be Completed by July ’89) 

-118-

Page 2 

Charter 

PDN Routing 

Specification of an X.25 Call Setup and Charging 

Determination Protocol (RFC-Draft, expected to be completed 

by Fall ’89) 

8) Specification of an X.25 Access and Forwarding Control 

Scheme (to be written up as an RFC-Draft by Fall ’89 or 

later) 

9) Specification of routing metrics taking X.25 charges into 

account (to be written up as an RFC-Draft by Fall ’89 or 

later) 

lO) Delayed TCP/IP header compression by VAN-gateways and 

PDN-hosts (new objective, will be considered Fall ’89 or 

later) 

11) 

12) 

Provide a testbed for worldwide interoperability between 

local TCP/IP networks via the system of X.25 public data 

networks (PDN) (starting June ’89) 

Implementation of the re~_aired algorithms and protocols in 

a VAN-BoX (Test version towards End ’89) 

13) Interoperability between ISO/OSI hosts on TCP/IP networks 

through PDN (1989/90) 

14) Consideration of INTERNET Route Servers (1990) 

15) Interoperability between local TCP/IP networks via ISDN 

(1990) 

Development of Internetwork Management Protocols for 

worldwide cooperation and coordination of network control 

and network information centers (starting 1990). 

-119-

PDN Routing Working Group 

Chairperson: Carl-Herbert Rokitansky/Fern University of Hagen 

STATUS UPDATE 

Chairperson: Dr. Carl-Herbert Rokitansky, Fern University of 

Hagen, D-5860 ISERLOHN, FRG 

E-Mail: roki@DHAFEU52.BITNET, 

Tel: ++49/2371/566-235 

roki@A. ISI.EDU; 

WG Mailing List(s) 

pdn-wg@BBN.COM: For internal discussions and information 

exchange between members of the PDN Routing working group. 

pdn-interest@BBN.COM: For information about: 

- Status report and proceedings of the PDN Routing WG 

- Draft proposals of documents and ]papers 

- Documents and papers published by PDN WG members 

- Important discussion on PDN Routing issues. 

pdn-request@BBN.COM: For people interested in being put on the 

"pdn-interest" mailing list. 

o 

® 

Date of Last Meeting: April IETF 1989, Cocoa Beach, FL 

Date of Next Meeting: Oct 31 - Nov 2, 1989, IETF/Univ of Hawaii 

(Intensive information exchange via e-mail meanwhile) 

® 


P06) Definition of the PDN-cluster addressing scheme as 

Internet standard: Expected to be written up as an 

RFC-Draft by Fall ’89. 

PO7) 

P08) 

PO9) 

Specification of Xo25 Call Setup and Charging 

Determination Protocol: Functionality, data structure and 

state diagram have already been defined, will allow 

reverse charging on international (!) X.25 connections, 

is currently in the progress to be written up as an 

RFC-Draft, and is expected to be completed by Fall ’89. 

Specification of an X.25 Access and Forwarding Control 

Scheme: Functionality and data structure have already 

been defined, might be included in the RFC-Draft above on 

X.25 Call Setup and Charging Determination Protocol, and 

is expected to be completed by late Fall ’89. 

Specification of routing metrics taking X.25 charges into 

account: Proposal is expected to be written up as an 

RFC-Draft by Fall ’89 or later. 

-120-

Page 2 

Status Update PDN Routing 

PO10) Delayed TCP/IP header compression: As a result from Van 

Jacobsons presentation (IETF, April 13, 1989), a delayed 

version will be considered to be used on X.25 connections 

by VAN-gateways and PDN-hosts, as a new objective (Fall 

’89) 

POll) Provide a testbed for worldwide interoperability between 

local TCP/IP networks via the system of X.25 public data 

networks (PDN): Several institutes and research 

establishments in Europe, USA and Australia have already 

agreed to participate in. these tests, which are expected 

to start in June ’89. 

POI2) Implementation of the re,fired algorithms and protocols in 

a VAN-BoX: All the algorithms and protocols specified 

above are intended to be implemented in a VAN-BoX (or on 

workstation) towards the end of 1989 (first test version). 

POI3) Interoperability between ISO/OSI hosts on TCP/IP networks 

through PDN: Will be tested and demonstrated in 

connection with national and international PDN-tests (see 

below). 

POI4) Consideration of Route Servers: Already discussed, but no 

detailed specification so far; will be considered with 

regard to results from international PDN-tests (see 

below). 

POI5) Interoperability between local TCP/IP networks via ISDN: 

First discussions and proposals were already made, will be 

considered in detail in 1990. 

POI6) Internetwork Management Protocols (cooperation of NOCs and 

NICs): Will be considered with regard to results from 

international PDN-tests (see above). 


PDN-cluster addressing scheme: 

Rokitansky, C.-H., "Internet Cluster Addressing Scheme and 

Its Application to Public Data Networks", in Proceedings of 

the 9th International Conference on Computer Communication 

(ICCC’88), pp. 482-491, Editor: J.Raviv, Tel Aviv, Israel, 

Oct 30 - Nov 4, 1988. 

¯ Hierarchical VAN-Gateway Algorithms: 

R0kitansky, C.-H., "Hierarchical VAN-Gateway Algorithms and 

PDN-Cluster Addressing Scheme for Worldwide Interoperation 

Between Local TCP/IP Networks Via X.25 Networks", in 

Proceedings of ITG/GI Conference on "Communication in 

Distributed Systems" (Informatik Fachberichte 205, 

Kommunikation in verteilten Systemen, ITG/GI Fachtagung, 

Stuttgart, P.J. Kuehn (Hrsg.), ISBN 3-540-50893-7 

-121-

Page 3 

Status Update PDN Routing 

Springer-Verlag Berlin Heidelberg New York~ ISBN 

0-387-50893-7 Springer-Verlag New York Berlin Heidelberg), 

pp. 758-774, Stuttgart, Feb 22-24, 1989¯ 

o Assignment of INTERNET/PDN-cluster network numbers to 

DNICs: Rokitansky C.-H., Fern University of Hagen, 

"Assignment and Reservation of INTERNET Network Numbers for 

the PDN-Cluster", RFC-Draft, Feb 1989. 

Assignment of default INTERNET/PDN-cluster addresses to 

VAN-gateways: Currently in the progress of being written 

up as an RFC-Draft, expected to be completed by July ’89, 

(might be included into the RFC-Draft above). 

¯ X.121 Address Resolution Protocol (first version has 

already been written up as an RFC-Draft to be discussed 

between members of the PDN Routing WG, and is expected to 

be completed by July ’89). 

-122-


Chairperson: Carl-Herbet iRokitansky/Fern University of Hagen 


Reported by Carl-Herbert Rokitansky 

AGENDA 

ATTENDEES 

Introduction 

Background information (European situation, X.25 Research 

Network) 

Report from CeBIT MultiNET TCP/IP demonstration on Hannover 

Fair, March 8.-15, 1989 (Carl-H. Rokitansky, FernUni) 

Status report on BBN-VAN-GATEWAY (butterfly replacement, 

EGP, etc.) (Mike Brescia, BBN) -Discussion 

Status and technical discussion of short term goals 

Assignment and reservation of PDN-cluster network numbers 

to national X.25 public data networks (DNICs), RFC Draft 

(Roki) 

Assignment of INTERNET IP addresses to VAN-gateways 

according to the developed hierarchical VAN-gateway 

algorithms (Roki) 

X.121 address resolution protocol, RFC Draft (Mike Brescia, 

Roki) 

Access control and reverse charging on international X.25 

connections 

Discussion on assignment of an autonomous system number to 

PDN 

Discussion on a modified EGP and routing metrics to be used 

between VAN-gateways 

Discussion of methods and requirements involving route 

servers 

Discussion on the application of the INTERNET cluster 

addressing scheme and developed gateway algorithms to 

Integrated Services Digital Networks (ISDN) to provide 

interoperability between local TCP/IP networks~through ISDN 

(Co Rokitansky, FernUni) 

Coordination of PDN Routing performance tests 

Discussion on documents to be published by members of the 

PDN Routing WG 

Assignment of action items 

Miscellaneous (mailing lists, etc.) 

Jerry Cronin 

Farokh Deboo 

Lionel Geretz 

Martin Gross 


John Moy 

Bill Nowicki 

Zbigniew Opalka 

2eeg-intg2@AFCC-OAI.ARPA 

..!sun!bridge2!fjd 

lioneI@SALT.ACC.COM 

martin@PROTOLABA.DCA.MIL 

lekash@ORVILLE.NAS.NASA.GOV 

jmoy@PROTEON.COM 

nowicki@SUN.COM 

zopalka@BBN.COM 

Carl-Herbert Rokitansky roki@DHAFEU52.BITNET 

Mary Stahl 

stahI@SRI-NIC.ARPA 

Rick Wilder 

rick@GATEWAY.MITRE.ORG 

-.123-

Page 2 

PDN Routing 

MINUTES 

X.25 Research Network (reported by C.-H. Rokitansky (Roki), Fern 

University): 

Towards the end of this year an "X.25 Research Network" will be 

installed and operated by the German PTT A large number of German 

universities and research institutes wil~ be ~connected to this X.25 

Research Network at fixed costs. A gateway to the German DATEX-P 

network will allow interoperation with the worldwide system of X.25 

Public Data Networks (PDN). 

Since most universities do have local TCP/IP networks, they are 

especially interested in exchanging TCP/IP datagrams with each other 

through this X.25 research network. An advantage of this kind of X.25 

network is the fact, that the exchange of network reachability 

information between hosts/gateways attached to the X.25 research 

network will NOT BE COST SENSITIVE, although we should try, of 

course, to limit the amount of such messages. 

Similar X.25 research networks will be made operational in other 

European countries, and they will probably be interconnected to an 

European X.25 research network one day. 

Report from CeBIT MultiNET (Mar ’89) TCP/IP Demo on Hannover Fair (by 

Roki): 

"The CeBIT MultiNET ’89 demonstration of system-independent networks 

was a further development of the two preceding MultiNET shows. 

MultiNET’s main object has remained unchanged: the joint presentation 

of international communication standards withproducts already 

available by a variety of EDP suppliers." (see slides presented at 

the Plenary) "Like before, CeBIT MultiNET ’89 demonstrates the 

current state of communications technology .... 

After a careful 

analysis of the actual needs of many network users, the following 

essential topics have been choosen for the CeBIT MultiNET ’89: I. 

coexistence and migration from TCP/IP to "ISO’"; 2. Network 

Management; 3. Network Applications .... 

The clearly defined range 

of functions together with the popular program interfaces and the 

broad use of the TCP/IP protocol family will surely, continue to 

stimulate the porting of network applications onto these 

communcication protocols, just as it has done up to now. Recently, a 

new algorithm for TCP/IP has been published, which offers 

considerable performance advantages for the protocol handling and 

which shows that TCP/IP is still being further developed. Some of the 

~r ax~rac~ i~p~emen~tions zrom ceBIT-MultiNET,,, are already based MultiNET on this Services new Gesellschaft algorithm.,, fuer 

Tale- und Datenkommunikation mbH, Venloer Strasse 131, D-5024 

Pulheim, FRG.) 

As can be seen from the slides, 32 suppliers demonstrated TCP/IP 

interoperability and ISO/OSI coexistence. The relatively great number 

of suppliers offering TCP/IP via X.25 (16), IP Router (17), 

Gateways (17), is of special interest for PDN Routing WG, although,of 

course, no dynamic routing of TCP/IP datagrams through the system of 

-124-

Page 3 

PDN Routing WorMing 

Group 

X.25 Public Data Networks is provided. Most suppliers expect an even 

increasing demand for the ~CP/IP protocol suite within the next 

years. 

Status Report on BBN-VAN-GATEWAY (Zbigniew Opalka, BBN): 

The current LSI-II/23 BBN-VAN-GATEWAY, will be replaced by a 

butterfly gateway by late May ’89. EGP will be available by then. 

Hierarchical VAN-Gateway Algorithms (Roki) 

The concept of hierarchical VAN-gateway algorithms, which allow the 

distribution of worldwide INTERNET network teachability information 

within a few number of hops in a very efficient way, were discussed 

in detail. A four level hierarchy is defined so far: I. LOCAL-VAN; 

2. DATA-NETWORK- VAN; 3.. COUNTRY-VAN; 4. ZONE-VAN. An additional 

level (REGION-VAN) might be specified between COUNTRY-VAN and 

ZONE-VAN. An advantage of the proposed algorithms is, that each 

VAN-gateway might have several direct neighbors, but there is ONE (!) 

only, which it has to call ACTIVELY for exchanging worldwide network 

reachability information. It is important to understand, that the 

whole data traffic will not necessarily be routed via the higher 

level VAN-gateways (level 2 to 4., which might be regarded as route 

servers in this case), but can be exchanged via a direct X.25 

connection (SVC) between LOCAL-VANs and/or PDN-hosts. The concept 

also provides for stupid LOCAL-VANs, which do not maintain worldwide 

network-reachability tables, but use their DATA-NETWORK-VAN as a 

default gateway. If this gateway knows a better route towards the 

destination network through the PDN, it sends an ICMP-Redirect 

message (similar to an ICMP Host Redirect message) to the calling 

LOCAL-VAN, specifying the INTERNET address of the next hop 

VAN-gateway, which can be any address in the PDN-cluster, (as an 

significant advantage of the INTERNET cluster addressing scheme). 

John Moy, Proteon, suggested to call this message "ICMP Gateway 

Redirect Message". 

Assignment and Reservation of PDN-Cluster Network Numbers to DNICs 

(Roki): 

This RFC draft contains a proposal for the assignment of INTERNET 

network numbers to existing X.25 national public data networks 

according to the proposed PDN-cluster addressing scheme, taking the 

structure of the X.121 international numbering plan for public data 

networks (6 zones worldwide) into account. The reservation (1024 

class B network numbers for the PDN-cluster) and the assignment is 

based on the expected growth of national public data networks in the 

various countries, and was done with regard to a specification of 

subclusters of the PDN-cluster (Europe-cluster, North 

America-cluster, North-Europe-cluster, etc.). Where possible, 

adjacent countries were assigned adjacent networks or subclusters, 

having in mind some kind of subcluster oriented (cartesian) routing 

algorithms for future use. A direct mapping between the INTERNET

Page 4 

PDN Routing Working 

Group 

network number and the corresponding DNIC can be performed by an 

algorithm for all US PDN-cluster network numbers within the 

North-American subcluster. 

The following Internet network numbers are reserved for the PDN 

cluster: 

188.000 - 188.255 

189.000 - 189.255 

190.000 - 190.127 

190.128 - 190.191 

190.192 - 190.255 

Europe 

North America 

Asia 

 

Pacific 

(Zone 2) , assigned: 

(Zone 3), assigned: 

(Zone 4), assigned: 

(Zone 5) assigned: 20 

191.000 - 191.127 

191.128 - 191.191 

191.192 - 191.255 

South America 

 

Africa 

(Zone 7) 

(Zone 6) 

assigned: 40 

assigned: 8 

A list of already assigned PDN-cluster network numbers is shown in 

the slides presented in the report at the Plenary. 

Assignment of INTERNET IP Addresses to VAN-Gateways and PDN-Hosts: 

According to the hierarchical VAN-gateway algorithms and the 

PDN-cluster addressing scheme, a proposal for the assignment of 

INTERNET addresses to PDN-hosts and VAN-gateways was presented by 

Roki and discussed in detail. This scheme allows to address a 

maximum number of 32.512 PDN-hosts [p.n.l.h] - [p.n.127.h] and 32.512 

LOCAL-VANs [p.n.128.v] - [p.n.254.v] in each national public data 

network to which an INTERNET (class B) PDN-cluster network number 

[p.n.r.r] has been assigned. In addition, 255 INTERNET addresses in 

each PDN network are reserved for higher level. VAN-gateways: 

DATA-NETWORK VANs [p.n.255.1] - [p.n.255.63] 

[p.n.255.64] - [p.n.255.127] resex~ed for future use 

COUNTRY VANs [p.n.255.128] - [p n.255.159] 

- [p.n.255.191] reserved for future use 

[p.n.255. 160] 

REGION VANs [p.n.255.192] - [p.n.255.207] 

future use [p.n.255.208] - [p.n.255 223] 

future use 

reserved 

reserved 

for 

for 

ZONE VANs [p.n.255o224] - [p.n.255.231] and 

(ZONE VANs) [p.0.255.224] - [p.0.255.231] "escape code" 

[p.n.255.232] - [p.n.255.239] reserved for future use 

WORLD VANs [P.n.255.240] - [p.n.255.243] reserved for 

future use [p.n.255.244] - [p.n.255.254] reserved for 

future use [p.n.255.255] ,Advantages of this 

hierarchical addressing scheme are: 

-126-

Page 5 

PDN Routing Working 

Group 

a bitmask can be used to distinguish between a PDN-host and 

a LOCAL-VAN 

a bitmask can be used to distinguish between 

PDN-hosts/LOCAL ’VANs and higher level VANs (level 2 VANs 

and up = [p.n..255.v]) 

a bitmask can be used to determine the functionality of 

each VAN-gateway 

each PDN-host or LOCAL VAN can determine automatically its 

default DATA NETWORK VAN (next higher level) [p.n.255.1] 

each (higher level) VAN-Gateway (and PDN-host) 

determine automatically its default top-level (ZONE VAN) 

an "escape code". [p.0.255.224] 

Access Control and Reverse Charging on International X.25 

Connections: 

. 

An access control scheme, proposed by Roki, has been discussed in 

detail with the group, and it was agreed that some access control in 

connection with charging determination is required for the routing of 

TCP/IP datagrams through the PDN, if we pro~vide worldwide 

interoperability. As a result from this discussion, a modified and 

more flexible "X.25 Access Control and Forwarding Scheme" was worked 

’ out after the meeting, and was presented in the PDN Routing WG report 

at the plenary (see slides)° 

Discussion on a Modified EGP and Routing Metrics to be Used Between 

VANs: 

Since there was not enough time to discuss this issue during the PDN 

Routing WG meeting, usage of ei’ther EGP2 or EGP3 was discussed with 

Marianne Lepp, Zbigniew Opalka, Roki and others at a "working lunch": 

Depending on the support for EGP3, either a modified version of EGP2 

or EGP3 will be considered to be used by VAN-gateways to exchange 

worldwide network reachability infoz~ation (eventually on an event 

driven basis). 

Implementation of the Proposed Algorithms in a VAN-BoX (or on 

Workstation): 

Fortunately, within the last year, the IETF-PDN Routing working group 

has developed most of the required PDN addressing schemes and gateway 

algorithms to allow a dynamic routing of TCP/IP datagrams through the 

worldwide system of X.25 Public Data Networks (PDN). The required 

algorithms and protocols include: 

PDN-cluster addressing scheme: 

proceedings; 

Hierarchical VAN-gateway algorithms: 

’89 Proc. 

published 

published 

in ICCC’88 

in ITG/GI 

-127-

Page 6 

PDN Routing 

Working Group 

Assign. ~Res. of PDN-cluster net #: 

published as RFC 

draft, ready to be 

Assign. ~Res. of PDN-cluster addr.: 

written up as an RFC 

currently being 

X.121 Address Resolution Protocol: 

published as an RFC 

draft, will be 

X.25 Call Setup and Charging Determ.: draft, currently 

being specified 

X.25 Access and Forwarding Control: 

being specified 

draft, currently 

Modified EGP2 or EGP3 between VANs: 

to be defined 

currently.in progress 

Delayed TCP/IP header compression: 

(new objective) 

will be considered 

By putting all these pieces together, it is intended to implement 

these algorithms, with support of the gateway companies (BBN, 

Proteon, SUN, 3COM, ACC, cisco, etc.), in a small "VAN-BoX" (and on 

workstation) with an Ethernet and an X.25 interface. By placing this 

"VAN-BoX" between a local TCP/IP network and an X.25 public data 

network, the implemented gateway algorithms will automatically 

exchange network reachability information to provide worldwide 

INTERNET interoperability between local TCP/IP networks through X.25 

Public Data Networks. 

Application of the INTERNET Cluster Addressing Scheme to ISDN (Roki): 

The application of the INTERNET cluster addressing scheme and the 

developed gateway algorithms to Integrated Se]~ices Digital Networks 

(ISDN) to provide interoperability between local TCP/I~ networks 

through ISDN has been discussed briefly. 

E. 164 specifies the numbering plan for the ISDN era. According to 

this numbering plan, the International ISDN Number (max. 15 digits) 

consists of the Country Code (CC), the National Destination Code 

(NDC) and the Subscriber Number (SN). NDC and SN form the National 

Significant Number (NSN) 

::= ; ::= ; 

or ::= . 

The INTERNET cluster addressing scheme could be applied to the 

ISDN by mapping cluster nets to CC or NDC. 

Internetwork scenarios for PDN-ISDN-PDN and ISDN-PDN-ISDN using 

X.121 or E.164 escape codes were discussed. Also the long-term 

PDN to/from ISDN solution using numbering ~ identifiers was 

sketched. 

-128-

Page 7 

PDN Routing 

Working Group 

Coordination of International PDN Routing Performance Tests: 

The developed PDN addressing schemes and VAN-gateway algorithms will 

be tested with participating sites in the following countries: 

Zone 2 (Europe) 

Germany: Fern University of Hagen (all VAN-gateway levels) 

GMD, St. Augustin (DFN-Gateway) 

University of Dortmund (UUCP-Gateway) 

University of Karlsruhe (BELWUE) 

University of Stuttgart (BELWUE) 

Austria: University of Salzburg 

Finland: University of Helsinki (NORDUNET) 

Italy: CNUCE, Pisa * 

Norway: NTARE, Oslo, (NORDL~.~ET) 

Sweden: SICS, Stoc.kholm (NORDUNET) 

UK: Portsmouth Polytechnic 

University College iLondon (INTERNET Gateway) 

Zone 3 

USA". 

Zone 4 

(North America): 

BBN, Cambridge, MA 

CISCO, Menlo Park, CA * 

PROTEON * 

SRI, Mehlo Park, CA * 

SUN, Mountain View, CA * 

(Asia)’. Israel ~., Japan ~o 

Zone 5 (Pacific): 

Australia: CSIRO 

Indonesia: LAPAN 

Zone 6 (Africa): 

Egypt 

Zone 7 (South America): Argentina ?, Brazil 

(* ... intended, but not yet agreed) 

(? ... these countries will.be contacted for participation, to 

have at least one representative site for each zone). 

First tests have already started within Ge~nany. International 

PDN-tests are expected to start in June ’89 between BBN and sites in 

Europe and Australia. 

Assignment 

of action items: 

Stahl: Check assignment and specification of INTERNET/PDN-cluster 

network numbers for US national public data networks for correctness 

(03, June ’89) 

Roki: Submit Internet Draft "Assignment and Reservation of the 

INTERNET Network Numbers for the PDN-Cluster" to IETF Chair and 

Reviewers (03, July ’89). 

--129-

Page 8 


Roki: Finish Internet Draft "Addressing Scheme for the Assignment of 

INTERNET/PDN-Cluster Addresses to VAN-Gateways and PDN-Hosts" for 

submission to the IETF Chair and Reviewers (04., July ’89). 

Opalka/ Finish Internet Draft "X.121 Address Resolution Protocol", 

Roki: for submission to the IETF Chair and Reviewers (06, July ’89). 

Roki: ~’, Write up Internet Drafts "INTERNET Cluster Addressing Scheme 

and "Application of the INTERNET Cluster Addressing Scheme to X.25 

Public Data Networks" for submission to the IETF Chair and 

Reviewers (05, Fall ’89). 

Roki: Write up an Internet Draft "Hierarchical VAN-Gateway Standards 

for Worldwide INTERNET Interoperability" for submission to the IETF 

Chair and Reviewers (05, Fall ’89 or later). 

Roki: Continue the specification of an Internet Draftt "X.25 Call 

Setup and Charging Determination Protocol" (07, expected to be 

completed by Fall ’89) 

Roki: Continue the specification of an Internet Draft "X.25 Access 

and Forwarding Control Scheme" (08, expected to be completed by 

Fall ’89 or later) 

Opalka/ Perform international PDN-tests according to the developed 

PDN- Roki: cluster addressing scheme and hierarchical VAN-gateway 

algorithms between USA (BBN) and sites in Europe (Fern University 

Hagen, University of Dortmund, University of Salzburg, etc.), 

starting June ’89 (Oil). 

A closed PDN Routing WG meeting was held during the afternoon session 

of April 12, where some of the PDN Routing objectives and action 

items were discussed in more detail.

4.~ I~ 

o 

X "--" 

r_. o r’7 

I 

Z 

"~ 

"el ~ 

Z 

> (1) 

Z 

fO °,,,4 

17 ~ 

i 

r.. 

4,-~ o~ 

0 -l.J I--I 

~: o ,-4 

o,-, Z l-- 

Z 

r7 

o 

o 

l.IJ 

I 

03 

03 

0 

r_ 

~ o 

o 

r_ 

4- CE 

o 

0 

c" 

~’~ 0 

o o 

°,4 

r- ~ W 

o 

03 o .,-4 

~ o .,-4 

~ 0 I-- 

.~..4 

,-4 .C: 0 

0 -~ 4- 

> 

°,4 0 F7 

0 

°,4 0 

I 

I 

I 

I 

I I I 

I 

-131-

¯ O0 O0 ¯ O0 ¯ 

O0 O0 0000 ~000 ¯ ¯ ¯ 

¯ O’ ¯ 

¯ 

¯ 

¯ ¯ ¯ O0 ¯ ¯ ¯ 

¯ O0 ¯ ¯ ¯ O0 ¯ 

¯ ¯ ¯ 

¯ ¯ O0 ¯ ¯ ¯ ¯ 

¯ ¯ ¯ 000 ¯ ¯ 

¯ ¯ ¯ gOD ¯ ~O~OOOOO 

I 

¯ OOO ¯ go ¯ ¯ OO go ¯ ¯ 

¯ ¯ ¯ O0 

¯ O0 OO0 ¯ O0 ¯ OOOOOO0 

¯ ¯ O0 ¯ ¯ OO0 ¯ OO000000 

¯ O0 ¯ O000 ¯ 000 ¯ ~O000000 

¯ ¯ ¯ OO00 OO0 000 O000 ¯ 

l 

¯ 

io o ~t ¯ ¯ o o ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ 

¯ ¯ ¯ ¯ ¯ ¯ ¯ ¯ 

¯ ¯ ¯ ® ¯ 

¯ ¯ ¯ ¯ ¯ 

O0 i0 O0 ¯ ¯ O0 O0 OO0000 

¯ ¯ ¯ 

O0 00000 ¯ OO0@O0000 ¯ 

O0 OO0 ¯ I O000 ¯ ¯ ¯ O00~O0000 

DO OO OO ¯ ¯ OO0 ~ OOOO0

Z 

O_ 

(11 

m 

0 

0 

H 

-134-

-135-

-].36- . .......

LEVEL 

p.n. 

¯ 

PPNx..- 

O.x ............. ,x 

VAN 

~..,~ Illlllll!OOx ...... 

¯ 

¯ 

x..x llllilllilOOx ...... ~ 

x..x IIIIIIIIillO~ ...... ~ 

~... Z~. Zo¢ 

x.x IIIIIIIl!lll 0~, ...... x 

__ 

1111 

¯ o ¯ 

x.x l|Illl IIiIII IIIOxxx 

1111111 

-137-

-138-

X. 7..5" 

! 

CALl- 

CALL 

CALL / 

(_kLL. 

P~oTOCoL. 

I .... 

CoHT’~H~E 

ONLY LJfl£H 

-13 9-

-140-

PDN-.Te s t s: 

Zone 2 (Europe): 

Germany: Fern Un ~ver’s ~y of H a g e n 

GMO, S~ ¯ August ~n (OFN-Gatieway) 

Un~ Oor ~mund (UUCP-Gateway) 

Un i Kar lsruhe (BEL wO 

Un i S~u~gart 

(BE:L~O) 

Austria: Un~vers ity of Sa lzburg 

Finland: Univers ity of He ls ink :i (NOROUNET) 

I Ea ly: CNUCE ? 

Norway: NTARE ? 

Sweden: SlCS (N 

OK: 

Portsmo 

UCL ? 

(NOROUNET) 

OROUNET) 

u~h Polytechnic 

Zone 3 

USA: 

(North America) 

BBN, Cambridge, MA 

CISCO, Menlo Park, 

ISI ?, Los Angeles, 

PROTEON, 

SRI, Nenlo Park, CA 

SUN, ~ountain View, 

CA 

CA 

CA 

Zone 4 (Asia) 

Israel ?, Japan 

Zone 5 (Pacif ic) : 

Australia: CSIRO 

Indonesia: LAPAN 

, 

Zone 7 (South 

Argentinia ?, 

Amer ~ca) 

Brasilia 

Rokltansky/FernUnl Hagen, FEB 1989 

-141-

-142-

Performance and Congestion Control 

Chairperson: Allison Mankin/Mitre 

CHARTER 

Description 


The charter of the IETF Performance and Congestion Control 

Working Group is to collect and develop short-term 

techniques for improving Internet performance, methods which 

like TCP Slow-start are retrofittable and inexpensive to 

implement. After a preliminary draft of a white paper 

documenting such performance enhancements for hosts and 

gateways, it was decided to sharpen the focus and divide tlhe 

material into two papers. 

One of the resulting papers is the RFC on gateway congestion 

control policies and algorithms. The intent of this paper 

is to present what is now known about the difficult problem 

of avoiding congestion in Internet gateways. It describes 

proposed policies such as Random Drop, Congesti,~n 

Indication, and Fair Queuing, and sketches ground-rules for 

their adoption. An additional goal of the paper (achieved 

during the writing) is to generate dialogue on longer-term 

Internet gateway performance problems. 

The other paper is an RFC on TCP performance. This 

describes TCP algorithms such as Retransmit Backoff, 

Slow-start, Nagle (Small-Packet Avoidance), and Delayed Ack, 

as well as their correct interaction. The scope is to 

expand the treatment of TCP performance found in the Host 

Requirements RFC. 

-144-

Performance and Congestion Control Working Group 


STATUS UPDATE 

1. Chairperson: Allison Mankin/mankin@gat.eway.mitre. org 

Name of WG Mailing List(s): 

ietf-perf (-request) @gateway. mitlre, org 

3. Date of Last Meeting: Cocoa Beach April 11-14, 1989 

4. Date of Next Meeting: Stanford IETF in July 


The other objective of the group is the TCP Performance RFC. 

This is in rough draft state at this point, but the hope is 

to complete its good draft by the July meeting. 


Gateway Congestion Control Policies 

We are closing in on completion of the RFC on gateway 

congestion control--the next revision (ready mid-May) 

will be placed in the IETF-DRAFTS directory for review 

by the IETF at large, and the contents will be 

presented in full at the July plenary. 

-145-




Reported by Allison Mankin/Mitre 

AGENDA 

ATTENDEES 

9-1 Tue: TCP Sub-Group 

2-5 Tue: GW Draft (Open) 

9-5 Wed: GW Draft (Members) 

Art Berggreen 

David Borman 

Noel Chiappa 

Mike Karels 


Charles Lynn 

Allison Mankin 

Matt Mathis 

Bill Nowicki 


John Scott 


art@sage.acc.com 

dab@cray.com 

jnc@ics.mit.edu 


lekash@orville.nas.nasa.gov 

clynn@bbn.com 

mankin@gateway.mitre.org 

mathis@faraday.ecc.cmu.edu 

nowicki@sun.com 

schofield@edn-vax.dca.mil 



MINUTES 

TCP Performance 

The TCP Sub-group met in Cocoa Beach to get organized and agree 

on the scope and orientation of the TCP Pelrformance paper. We 

agreed that the paper will expand on the Host Requirements RFC 

treatment of algorithms such as Retransmit Backoff, Slow-start, 

Nagle Small-Packet Avoidance, and Delayed Ack, and their correct 

interaction. It will be ancillary to the Host RFC; 

particular, it will support the Host RFC’s Musts, Shoulds and 

Mays. 

A list of topics for scope had been generated by going through 

RFC-793 and the Host Draft. The group marked these according to 

our sense of the state of knowledge: Y if well understood, M if 

incompletely understood. We defined N for not understood, but 

only used it for Type of Service, because it seems orthogonal to 

TCP performance. 

TCP Performance 

RFC Topics 

Certainty 

Maximum Segment Size 

TOS 

Precedence 

Connection Establishment 

Management of TCBs 

M 

N 

M 

Y 

Y

Page 2 


TCP Performance RFC Topics (chart con’t from pg i) 

Connection Reuse Y 

PUSH 

Y 

Sender Silly Window Avoidance 

Y 

Nagle Small Packet Avoidance 

Y 

Slow-start Congestion Avoidance Y 

Relationship of Nagle S.-S Y 

RTO Calculation 

Y 

Rxt Amount 

Y 

Rxt Backoff 

Y 

Response to Source Quench Y 

Window Upper Limits 

M 

Zero-window SWS Cant--Send State M 

Receiver Silly Window Avoidance Y 

Out-of-order Processing Y 

Delayed ACK 

Y 

Piggy-back ACKs M 

Application-TCP Interface Y 

Fairness Among Connections Y 

Interface of TCP to IP M 

Fair Processor 

Y 

Connection Instrumentation Y 

Extended Window Option Y 

High-Speed Implementation Techniques M 

Off-board Issue M 

Certainty 

Many of the attendees took action items to be responsible for 

topics. For quite a few of the topics, the members of the 

sub-group local to Washingtont D.C. wrote drafts already, and 

these will be distributed. 

Gateway Congestion Control 

The rest of the working group time in Cocoa Beach was devoted to 

the Gateway Congestion Control Policies paper, now nearing 

release to the IETF. At the January meeting we had decided to 

recommend Random Drop in the paper. We revised the paper during 

the interim so that it detailed the RD policy more and gave it a 

fairly caveated recommendation (stating that experimentation was 

needed before any algorithm would be descrilbed). 

The paper stimulated some comment. Lixia Zhang and Eman Hashmen 

(MIT) separately.did simulation experiments on RD. Scott Shenker 

(Xerox PARC) did some analysis of RD as a sideline to a paper 

is writing on. game theory and gateway performance. All three 

have ongoing work on gateway congestion control algorithms that 

derive from Fair Queueing. 

-147-

Page 3 


Chuck Davin gave an informal presentation of the MIT results on 

Tuesday afternoon. Scott’s insights were offered in a long mail 

message, which was distributed to the working group. 

A bottom-line 

summary of the studies: 

RD as congestion control (choose random packet to drop instead .of 

first or last on queue) is uncontroversially viewed as a win. 

With RD, non-cooperating TCP gets excessive bandwidth at the 

expense of Slow-start connections. 

RD (and other policies) give too much control feedback "to 

connections whose RTTs (paths) are longer than others sharing the 

resource. Host-pair state as in FQ or SF (DEC Selective 

Feedback) is one cure. 

Random Drop will remain at the center of the paper, but with 

explication of the performance problems it handles well and of 

its limitations. Its good properties for control (at queue 

overflow) will be made clearer. We will expand the sections on 

other policies and make a number of other changes suggested by 

the ten or so non-member reviewers who read the draft this time 

(and whom we thank wholeheartedly). Some of these changes are: 

Clarify distinction between congestion control and 

avoidance. 

Expand RD congestion control vs. RD congestion avoidance. 

Present the components of control system (congestion 

detection, feedback method, feedback selection). 

Survey congestion detection methods. 

In RD CA, constant and adaptive probability of drop. 

Survey the time constants identified for gateway 

performance, i.e. the interval used for averaging in 

congestion detection. 

These changes are not as onerous as they sound. The paper will 

be redistributed in mid-May. At the same time, it will become an 

IETF-DRAFT. We will try for an interim meeting, perhaps, despite 

it not being great for everyone, on the day before INARC (May 

31) 

Some follow-on studies will be going on. One that came out of 

Cocoa Beach: at the open meeting on Tuesday, Rick Boivie and 

Yakov Rekhter offered to set an RT instrumented by Van into the 

NSSs to allow characterization of the time constants of backbone 

gateways, 

-148-

-149-

Point-to-Point Protocol Working Group 

Chairpersons: Drew Perkins/CMU and Russ Hobby/UC Davis 

CHARTER 

Description 


The working group is defining the use of serial lines in 

data networks. While the main intent is to standardize the 

connection of IP networks over point-to-point links, the 

protocol is being designed to be extensible to other network 

protocols as well. The protocol will provide the capability 

of establishing the link parameters, authentication, link 

encryption, link testing, as well as control of the link 

while it is up. The protocol will also allow configuration 

and control of the higher level protocols such as IP, OSI, 

802.3 bridging, and others. 


The main objective of the workgroup is to produce an RFC 

defining the protocol for the link and IP levels. 


The final draft of the RFC will be completed for the Fall 89 

IETF Meeting. 

-150-


Chairpersons: Drew Perkins/CMU and Russ Hobby/UC Davis 

STATUS UPDATE 

i. Chairpersons: 

Russ Hobby, University of California - Davis, 

rdhobby@ucda~vis, edu 

Drew Perkins, Carnegie Mellon University, 

dpp @ andrew, cmu. edu 

¯ 

¯ 

¯ 

¯ 

WG Mailing lists: ietf-ppp@ucdavis.edu - main mail list 

ietf-ppp--request@ucdavis, edu - requests 

for addition to Joist 

Last meeting: Cocoa Beach, April 1989 

Next meeting: Stanford, July 23-24, 1989 


Produce RFC on protocol definition, final draft expected 

Fall 89, :[ETF meeting. 

o 

Progress to date (e.g., documents produced): 

o Requirements for a Point-to-Point Protocol, Perkins 

September 1988. 

o Complete protocol definition of link configuration and 

control¯ Definition of IP c.onfiguration and control 

being finished¯ 

--151-

Point-to-point Protocol Working Group 

Chairpersons: Russ Hobby/UC Davis and Drew Perkins/CMU 

CURRENT 

Reported 


by Russ Hobby 

I. Introduction 

The PPP WG met on April Ii and 12. The work group plans to have 

the current work written up and have one or two video conferences 

before, the next IETF meeting. 

Work was continued from where it was left at the video conference 

with the decision to handle configuration of the link and upper 

level protocols separately. The link must be up and ready before 

any of the upper level protocols can be configured and started. 

Once the line is up the upper level protocols may be brought up 

and taken down at any time. If the link goes down, the interface 

must inform the upper level protocols so that they may take 

appropriate action. 

The group defined the protocols and procedures to bring the line 

up and work was started on the control protocol t6 bring up IP. 

The link must be brought up by the following sequence: 

l® 

Configuration exchange - this step is not completed until 

a Config Ack has been both received and sent. All 

configuration items are assumed to be at default values 

until d . configuration exchange is complete 

o Authentication - authentication methods used are those 

agreed to in the configuration exchange if any. 

Authentication is accomplished using the PCP Authentication 

Protocol. A simple user/password authentication method is 

defined. Development of other methods is encouraged. 

Encryption turned on - encryption methods used are those 

agreed to in configuration exchange if any. Only the data 

fields of PPP packets are encrypted and PCP packets are 

never encrypted insuring the control messages can get 

through even if encryption methods are out of sync. 

Currently no encryption methods are defined. 

Line testing - check if line quality is sufficient to bring 

up upper level protocols. Suggested methods of line testing 

are being defined (Medin and Satz). 

5. Line up - ready for upper level protocols. 

If any control packets are received that do not conform to 

the sequence, the equence is restarted. At any time if a 

data packet, as opposed to a control packet, is received 

-152-

Page 2 


for an unknown protocol or a protocol that is not up, the 

packet is dropped. 

II. PPP Control 

Protocol 

As it was reported from the last IETF meeting, HDLC is the 

link packet format and in the data section of the packet is 

a field indicating the protocol in ’the remainder of the 

data. One the these protocols, number 33, is the PPP 

Control Protocol (PCP) used to configure and control the 

link and upper lew~l protocols. PCP packets have a 16 bit 

protocol number field. After tlhe protocol field the data 

can used as desired for configuration and control by each 

protocol. 

0 1 2 3 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 i 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+o~+-+~+-+-+-+-+-+-+-+-+ 

iprotocol (value=33) I o protocol 

data 

III. Link Control Protocol 

Protocol 0 of the PeP, the Link control Protocol (LCP) 

used to configure and control the link itself. LCP includes 

functions for establishing the initial configuration, 

determining loopback, up/down control, circuit disconnect 

and other functions. 

-.153-

Page 3 


The PCP packet is as follows: 

0 1 2 3 3 

01234567890123456789012345678901 

+-+-+-+-+-+-+-+_+_+_+_+_+_+_+_+_+_+_+_+_+~+_+..+_+_+_+_+_+_+_+_+.o+ 

I protocol (value=0) I version I type I 

magic number 

data 

A. Version - The version of LCP supported. 

B. Type - Type of LCP packet. Defined types are: 

1 - Configuration 

3 - Config Huh? 

5 - Version Reject 

7 - Terminate Request 

9 - NOP 

II- Echo Request 

13- Protocol Unknown 

2 - Config Ack 

4 - Config Nak 

6 - Type Reject 

8 - Terminate Ack 

I0- Keep Alive 

12- Echo Reply 

Magic Number - This pseudo-random number is used to 

uniquely identify an end of the point-to-point 

connection. This field is used to detect if a line is 

looped back to itself. Once a number is selected the 

same number is used for the duration for the 

connection. All LCP packets sent out must contain the 

senders magic number (See discussion on loopback 

detection) 

Do 

Data - Additional data associated with the packet type. 

LCP Packet Types 

lo 

Configuration - This packet type is sent out the 

line to indicate pertinent configuration 

information and is used to establish a connection. 

Receipt of a Configuration packet means that the 

line is being reset and restarted. Exchange of 

configuration packets can continue until both 

sides send Config Acks or one side gives up. If 

no response is received from the other side after 

a timeout period, the Configuration packet can 

be resent. Suggested timeout period is three 

seconds. 

-154-

Page 4 


Configuration Items (CI) are placed in the data 

field of the PCP. Multiple CIs may be included in 

each packet. The format of a CI is: 

0 1 2 3 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-.+-+-+-+-+-+-+-+-4--+-+-.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

length I CI type I 

data + 

a. Length - inclusive length of the CI. 

b. CI Type - Type number of the CI. 

c. Data - value or other information for the CI. 

CIs provide information on M~U, async character 

mapping, link authentication method and link 

encryption method. If a CI is not included in the 

config packet, the default is assumed. The end of 

the list of CIs is indicated by a zero length CI. 

Config Item 

1 - Max Receive Unit 

2 - Async Control Char Map 

3 - Authentication Type 

4 - Encryption Type 

5 - Keep Alive Parameters 

Bits Default 

16 1024 

32 all ones 

16 none 

16 none 

?? none 

Sync lines will accept any value for the Async 

Control Char Map. 

Config Ack - This packet type is sent in response to a 

configuration packet and indicates acceptance of the 

other ends CIs. LCP data field contains CIs of 

accepted configuration, 

o 

o 

Config Huh? -o This packet type is sent in response to 

a configuration packet and indicates the configuration 

packet contained unknown CI type(s). The LCP data 

field will contain the CI entries of the unknown types. 

Config Nak - This packet type is sent in response to a 

configuration packet and indicates the configuration 

packet contained unacceptable CIl[s). The LCP data 

field will contain the CI entries of the unacceptable 

CI(s) and may contain suggested new values. 

-155-

Page 5 


5, Version Reject - This packet type is sent in response 

to a LCP packet of an unacceptable version. The packet 

will return an acceptable version number. 

o 

. 

Type Reject - This packet type is sent in response to a 

LCP packet of an unacceptable type. Any information in 

the LCP data field may be ignored. 

Terminate Request - This packet type is sent to 

indicate the connection is going to be terminated. If 

possible wait for the Terminate Ack before breaking the 

connection. Any information in the LCP data field may 

be ignored. 

. Terminate Ack - This packet type is sent in response 

a Terminate Request° Any information in the LCP data 

field may be ignored. 

NOP - This packet type may be used to send non-LCP 

related data on the line, such as modem control 

information. When received the packet will be 

discarded. 

10. Keep Alive Parameters - To be defined. Note: Both sides 

must agree on common parameters for keep alives. 

II. Echo Request - This packet type is sent requesting that 

an echo reply packet be returned. ~y information may 

be placed in the LCP data field. 

12. Echo Response - This packet.type is sent in response to 

the echo request packet. The LCP data field must be a 

copy the LCP data field of the request. 

Protocol Unknown - This packet is sent in response to a 

PCP packet of an unknown or unimplimented protocol. The 

data field contains the 16 bit value of the unknown 

protocol. 

IV. Authentication 

Protocol 

Protocol 1 of PCP, the Authentication Protocol, is used to 

verify the entity on the other end of the link. The 

authentication method agreed to in the colnfiguration 

exchange is the method an entity will use in verifying the 

other end. Each end may use a different method if agreed in 

the configuration phase. 

-156-

Page 6 


0 1 2 33 

01234567890123456789012345678901 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

protocol (value=l) I authentication type 

data + 

The data field may be used in any way defined by the 

authentication method. 

A simple user/password (auth type = l) method is defined 

here. 

I Auth type I operation 

value = 11 

16 bits I 8 bits 

I 

data 

N bits 

V. IP Control Protocol 

request I user l en I user I pass l en I pass I 

I value = 1 I in bytes I string I in bytes I string l 

I 8 bits I I 8 bits I I 

I ack I msg len I msg I 

I value = 1 I in bytes I string I 

I I 8 bits I I 

I nak I msg l en I msg I 

I value = 1 I in bytes I string I 

1 8 bits I I 

Protocol 35 of the PCP, the IP Control Protocol (ICP) 

used to configure and control the IP protocol. ICP includes 

functions for establishing the initial configuration, taking 

down the protocol and other functions. The ICP packet 

format is as follows: 

0 1 2 33 

012345678901234:56789012345678901 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

protocol (value=35) I version I type 

data + 

-.157-

Page 7 


Version - The version of ICP supported. 

So 

Type - Type of ICP packet. 

1 - Configuration 

3 - Config Huh? 

5 - Version Reject 

7 - Terminate Request 

9 - NOP 

Defined types are: 

2 - Config Ack 

4 - Config Nak 

6 - Type Reject 

8 - Terminate Ack 

The ICP functions above work the same as for their 

counterparts in the LCP section. The CIs for~ICP are: 

Configuration Item 

i. Addresses 

2. Compression Method 

Bits 

Default 

?? none 

?? none 

IP Address Negotiation 

On Init 

Send REQ w/ my IP addr or 0 if unknown° 

Receive ACK w/ both addresses (1) 

Receive NACK. Can retry REQ w/ a different address. 

On Recv REQ 

Remote addr set if likeremote addr then ACK w/both 

addresses else NACK 

Remote addr not set pick an appropriate remote addr and 

ACK w/ both addresses.(2) 

Note i: If remote addr is 0 then ignore it. He’ll be 

soon asking you to set it so remember it then. 

Note 2: If have no idea what to pick (such as both 

ends ask each other end for its address) then give 

defaults, 127.0.0.X for one with smaller magic number 

and 127.0.0.X+I for one with larger. There is 

discussion if the net 127 address is reasonable and 

what the value of X should be. 

-158-

V 

-159-

-160-

ST and Connection IP Working Group 

Chairperson: Claudio Topolcic/BBN 

CHARTER 

Description 


Define the next version of the ST protocol, explore future 

connection oriented internet protocol, use the former as a 

testbed to perform experiments in support of the latter. 


Produce a new specification of ST 

Produce a specification of a next generation connection 

oriented protocol 


a) 

b) 

Produce a new specification of ST. (2-3 months) 

Produce a specification of a connection oriented 

protocol. (6-12 months) 

-162-


Chairperson: Claudio Topolcic/BBN 

STATUS 

UPDATE 

1. Chairperson: Claudio Topolcic, BBN Labs, topolcic@bbn.com 

2. Name of WG Mailing List(s): cip@bbn.com 

3. Date of Last Meeting: April 12, Cocoa Beach Florida 

4. Date of Next Meeting: July 25, Stanford 

5. Pending or New Objectives: none 

6. Progress to Date (e.g., documents produced) 

o Internal draft of ST Specification 

o Numerous e-mail messages describilng issues in 

connection oriented protocols 

___ -163--

St and Connection IP Working Group 

Chairperson: Claudio Topolcic/BBN. 


Reported by Steve Casner/ISI and Claudio Topolcic/BBN 

AGENDA 

ATTENDEES 

Characterize applications 

Define functions of the internet layer 

Identify implications on underlying networks 

ST- discuss a number of issues we had not yet agreed to 

Ross Callon 

Steve Casner 

Danny Cohen 

Phil Draughon 

Phil Park 

Zaw-Sing Su 


Paul Tsuchiya 


casner@isi.edu 

cohen@isi.edu 

jpd@accuvax.nwu.edu 

ppark@bbn.com 

zsu@sri.com 

topolcic@bbn.com 

tsuchiya@gateway.mitre.org 

MINUTES 

The working group held two meetings, which correspond to the 

two tracks we are pursuing. The meeting held during the day 

9f ’ Wednesday 12 April covered the high level and long term 

issues of connection oriented internet protocols. A second 

meeting was held in the evening of 12 April. It covered a 

number of short term issues that need to be discussed to 

finalize the ST specification. 

COIP Meeting of April 12, 1989: 

Phil Park~gave a presentation on Application 

Characterization, following the message he sent out. 

Applications are characterized by a list of parameters: 

packet size, packet rate, etc. We are calling these the 

"Quality of Service" (QOS) parameters. 

Danny proposed an additional parameter indicating how long a 

connection is expected to last; e.g., for’ FTP, saying how 

long the file is, or for a teleconference, how long it will 

run. It’s not clear just how this will be used. Perhaps we 

need only two values: short (transient, don’t count it), 

and long. If only two values are necessary, then it was 

argued that the "transient" transfer is equivalent to 

datagram service and could be supported by a datagram 

internet layer rather than a connection oriented internet 

layer. 

-164-

Page 2 

ST and Connection 

IP Working Group 

Although the problem of resource management in the network was 

not discussed, a possible use of this information is the 

following. We can imagine that the management might occur on 

several levels. Part of that management might be scheduling of 

resources on a time scale of tens of minutes .to hours. If we 

want to establish a connection for a teleconference, and. can 

specify that the teleconference is to last two hours, we might 

want the connection to be refused if my resources are going to be 

preempted by a higher-priority teleconference that has been 

scheduled to begin in five minutes. Or, we might want a 

different route to be chosen if such a conflict is encountered 

and an alternate route is possible. (If automatic rerouting with 

minimal disruption is possible, then maybe we don’t have to care 

about this route choice initially.) This sc.enario presupposes 

scheduling protocol which is likely to be outside the scope of 

the connection oriented internet layer as we envision it now. 

However~ if scheduled connections are to be considered, then 

there must be some interaction between the scheduling mechanism 

and the connection establishment meclhanism. Also a network’s 

decision to accept a connection may ibe based on administrative 

policies. Those policies may allow use of a network as long as 

you don’t hog it. The duration of a teleconference or the size 

of a file transfer would be one measure to be considered in such 

a policy. 

There are some parameters that applications give to nets, and 

some vice versa. Steve asserts that it’s best to have full 

information transfer both ways so that nets can make decisions 

based on the information when they care. There’s not much 

penalty in providing too much information. 

Some of the parameters that stimulated discussion are the 

following: 

Bandwidth -- don’t want a linear scale° 

Packet size -- Danny proposed that the network should report 

back the maximum packet size available along the complete 

path, rather than having the application say what packet 

size it wants. BUT -- the Wideband Network, for example, 

needs to know the size packets to be sent in order to 

efficiently allocate a stream to match° It was agreed that 

once a connection was established, the maximum packet size 

along that route could be reported to ~the application to 

provide it some flexibility. 

Reliability -- need only a few choices: perfect, a lot, a 

little, don’t care. This is true unless you are really 

controlling something like coding, then you need enough bits 

to specify the range of control settings. Ross suggested we 

select levels that whose results we can understand, 

specifically: 

--165-

Page 3 

ST and Connection 

IP Working Group 

i) 

2) 

3) 

~) 

The reliability supplied by TCP to an application. 

The reliability over which TCP works efficiently. 

The reliability across which voice works well. 

The reliability over which TOP will collapse. 

Don’t care. 

Delay -- this is a "softer" requirement than bandwidth. We 

couldn’t figure out how an agent could guarantee a given delay, 

nor what it should do if it could not meet it. 

Security -- may affect routing decisions, or processing load in 

agents if they have to decrypt headers, but for real security, 

applications don’t get a choice, so there may be no point in 

including this parameter. Security should be supported by SDNS. 

Burst factor -- this should be covered in the rate parameters if 

they are rich enough to describe the distribution. Later, we were 

not so sure, and considered a "leaky bucket ’u parameter, i.e., how 

big does the bucket (buffer) have to be to avoid overflowing 

given an outputat the bottom with a flow at the average rate. 

Danny suggested that we have shorthand codes for various traffic 

types. This was based on the observation that in NVP-II we had a 

full set of parameters but.only ever used the "vocoder codes" 

that were a shorthand for the full set. Steve suggests the 

reason is that we never did vocoder experimentation over the net; 

we experimented in the lab, then used completed vocoders over the 

net. For application characterization, the con~unication of 

parameters is not between peers, but between layers. Steve 

suggests there will beta wider variety of applications, and that 

at least some parameters will require numerical adjustability if 

a shorthand is defined. 

Danny suggested that each packet could carry a priority 

specification. Then the high priority packets would be processed. 

first. Ross suggested an alternate approach, in which a 

connection would have a priority, and this priority would be used 

as input to the decision to accept, reject or pre-empt that 

connection. It would be the entire connection, not any given 

packet that would be deleted. This approach was more popular 

among the attendees. This discussion brought out two interesting 

questions. In times of congestion, should a connection be singled 

out and pre-empted, or should packets from a number of 

connections be dropped without pre-empting any given connection, 

and how would the connections be selected? Second, how it could 

be decided that the requirements of an established connection 

could no longer be met and that connection should be pre-empted? 

Neither of these issues were resolved. 

Nevertheless, allowing packets in a connection to have different 

priorities supports a single application that carries data of 

different priorities. This would be the case if we are using a 

layered coding scheme where lower priority layers get discarded 

-166-

Page 4 


if there is congestion. If this were done with separate 

connections each with its own fixed priority, that could cause 

problems with synchronization. We did not resolve this issue. 

We discussed how the values of these parameters would be arrived 

at. There can easily be flexibility in what an application can 

accept. Possible reasons include a) in many applications packet 

size and packet rate can be traded off and so long as they 

represent the same bandwidth, since many applications only care 

about bandwidth, b) some applications can transmit , comparable 

data at different bandwidtlhs, such as when using multiple rate 

voice coders, or c) some applications, such as file transfer, can 

adapt their behavior to offer different bandwidths. Therefore, it 

is reasonable to assume that there can be a negotiation of these 

parameters between the application and the network layer. 

In negotiating packet rate and packet size, there are two 

distributions to consider: l) the range ower which the 

application can operate (its adjustability)~ and 2) the range 

over which it varies as it operates (for variable-rate coding 

schemes). For (i), the application would want to give 

values, what it needs (min) and what it wants (max). For (2), 

variable rate application would want to specify the average rate 

(what it wants to pay for) and the peak rate it wants the network 

to handle. Specifying ranges of average and peak values won’t 

work because the network can’t "tell what value of peak goes with 

a given choice of average (or vice versa). Instead it might 

better to give a list of (avg,peak) pairs; each pair would 

specify a range of type (2), while the collection of pairs would 

specify the range of type (i). However, there is a problem, the 

packet rate and packet size are related; either might be fixed 

while the other changes (either for adjustability or 

variability). So, it might be necessary to specify a list of 

quadruples: (avg rate, peak rate, avg size, peak size) where 

avg=peak for at least one of rate or size. 

The parameters 

list that ~we arrived at is the following: 

Bandwidth - (avg pkt rate, peak pkt rate, avg pkt size, peak pkt 

size) 

Delay - (maximum tolerable at some percentile, some indication 

of acceptable distribution, flag to allow discard) 

Reliability - (some small number of values) 

Discard option - (newest or oldest) 

Total duration of transfer - (?) 

Burst factor o- (?) 

We finally decided that we need to look at what the network will 

do with this information before we can say much more about the 

negotiation process. We decided that the next step should be to 

talk about the network layer and we should then come back and 

take another pass at characterizing the applications and defining 

the negotiation procedure. 

-167- ___

Page 5 


ST protocol specification meeting of 12 April 1989 

ATTENDEES 

Steve Casner, Danny Cohen, Phil Draughon, Phil Park, and 


We met for a few hours the same evening. We reached a number of 

decisions and agreed not to decide on a number of other issues. 

DECISIONS 

We reviewed Steve Casner’s proposal for doing encapsulation of ST 

packets in IP for the purpose of sending the ST packets across 

IP-only parts of the Internet. We approved it. In this 

technique, an IP header is placed in front of an ST packet and 

the IP destination is set to be the IP address of the next ST 

agent along the ST connection’s route. This is used when the best 

route includes passing through gateways that do not support ST. 

Since the IP-only gateways and networks cannot perform resource 

management, we assume that this will only be the case when that 

IP-only part of the Internet is only lightly loaded. 

Danny suggested using this IP encapsulation technique for all ST 

packets. Again, the IP destination would be the IP address of 

the next ST agent, even if that agent is the next gateway in the 

path. ST agents would still perform all the resource management 

functions they would if the packets were not so encapsulated. 

The motivation would be to take advantages of security 

implemented for IP as part of SDNS, or other services provided 

with IP. Everyone was intrigued, but we. weren,t convinced that 

this would be of enough benefit. We did not accept this view at 

this time. We agreed that it is not mandatory for the new ST 

specification to maintain the same interface with the next higher 

protocol layer as current ST. However, changes should be based on 

sound reasoning. Specifically, we may cause the next higher layer 

to need to have more information than current ST does. Phil 

Draughon offered to look into the requirements of the next 

protocol layer. 

We agreed that we will need to write more specification documents 

than just the ST spec we are currently working on. We need to 

describe things like the interface between the ST layer and the 

next higher layer in a host, and the routing algorithm that will 

be used. 

We agreed that adding new control messages to ST is acceptable, 

but only as long as the new ones have a different and distinct 

function. 

We decided to get rid of the ST.DG bit. 

-168-

Page 6 


We agreed that a source route option would be a good idea, and 

thought it would be relatively easy to implement, though we did 

not decide on a mechanism. 

We agreed with Danny’s proposal that security be provided by 

SDNS. IP encapsulation will be necessary to allow this. 

NO DECISION 

REACHED 

We talked about the impact of what we are doing with the 

conferencing part of ST on the point to point part of ST. We 

could try to not force any changes on the point to point ST, we 

could make only the obviously necessary changes, such as using a 

consistent Flow Spec, or at the other extreme, we could eliminate 

point to point ST altogether. Making point to point ST be simplex 

is equivalent to eliminating it.. We did not make a decision 

because nobody had a particularly strong opinion. 

We talked about the possibility of changing the route of an 

established connection, but we decided this was hard and we would 

postpone a decision. 

We agreed that aggregation will be useful, and also agreed that 

it will be hard to specify and implement. We did not discuss how 

to do it. 

We discussed whether a field would be needed that specifies the 

next protocol above ST. Such a field exists~ it is the extension. 

However, we did not agree how that field should be interpreted. 

An obvious possibility is to partition the space and assign 

different parts to different protocols. 

Somebody suggested adding a flag, and function, that causes the 

reverse path of a (conference) connection to be built 

automatically, in essence allowing conferencing connections to be 

full omniplex. We decided to table this idea for now. 

We did not discuss 

routing. 

-169-

-170-

TELNET Working Group 

Chairperson: Dave Borman/Cray 

CHARTER 

Description 


The TELNET working group is to look at RFC 854, "Telnet 

Protocol Specification", in light of the last 6 years of 

technical advancements, and determine if it is still 

accurate with how the TELNET protocol is being used today. 

This group will also look at all the numerous TELNET 

options, and decide which of them are still germane to 

current day implementations of the TELNET protocol. 

Specific 

Objectives: 

Either re-issue RFC 854 to reflect current knowledge 

and usage of the TELNET protocol, or issue a companion 

RFC to update and expand on fuzzy areas of RFC 854. 

Create or update RFCs for TELNET options to clarify or 

fill in any missing voids in the current option set. 

(Most noteably, some method to allow automatic user 

authentication is needed). 

~ Act as a clearing house for all proposed RFCs that deal 

with the TELNET protocol. 

o When the above objectives have been met, go dormant, 

and will be re-activated as needed to fullfill the 

objective of being a clearing house for future 

extensions to the TELNET protocol. 


Estimates will be determined after the first meeting. 

-172-

TELNET Working Group 

Chairperson: David Borman/Cray 

STATUS UPDATE 

i. Chairperson: Dave Borman~ dab@cray.com 

2. WG Mailing List(s): telnet-ietf@cray.com 

(Subject to change..°) 

3° Date of Last Meeting: New Group 

4. Date of Next Meeting: July 1989 at Stanford 


6. Progress to Date (e.g~, documents produced): 

none 


none 

-173-

USER-DOC Working Group 

Chairpersons: Tracy LaQuey/Univ of Texas and Karen Roubicek/NSF 

CHARTER 

Description of Working Group: 

The USER-DOC Working Group will prepare a bibliography of on-line and hard 

copy documents/reference materials/training tools addressing general 

networking information and "how to use the Internet". (Target audience: 

those individuals who provide services to end users and end users 

themselves.) 

Specific 

Objectives: 

Io Identify and categorize useful documents/reference materials/training 

tools. 

2o Publish both an on-line and hard copy of this bibliography. 

3o Develop and implement procedures to maintain and upda~e the 

bibliography. Identify an organization or individuals to accept 

responsibility for this effort. 

As a part of the update process, identify new materials for inclusion 

into the active bibliography. 

5o Set up procedures for periodic review of the biblio by USWGo 


- Format for the bibliography will be decided upon by the 

July IETF session, as well as identification of "sources of 

information" (e.g. individuals, mailing lists, bulletins, etc.) 

- Draft bibliography will be prepared by mid-December 89. 

-174-


Chairpersons: Tracey LaQuey/Univ of Texas and Karen Roubicek/NSF 

STATUS UPDATE 

io Chairpersons: Tracy LaQuey / tracy@emx.utexasoedu 

Karen Roubicek / roubicek@nnsc.nsfonet 

2o WG Mailing Lists: us-wg@nnsconsf.net (temporary?) 

us-wg-request@nnsc, nsf ~ net 

3° Date of Last Meeting: JVNC Supercomputer Center, Princeton NJ / 1 Jun 89 

4. Date of Next Meeting: July IETF meeting/10:45am - 4:00pm, 25 July 89 

Stanford, CA. 

5. Pending or New Objectives: see Current Meeting Report 

6o Progress to Date (e.g., documents produced): 

Ist formal meeting 1 Jun 89 / draft charter and objectives drawn up 

-i ’7 5-


Chairpersons: Tracey LaQuey/Univ of Texas and Karen Roubicek/NSF 


Reported by Karen Bowers 

Several members of the USWG took the opportunity to convene a WG session 

during the FARNET meeting at the JVNC Supercomputer Center, Princeton, NJ 

on 1 June 1989. The purpose of this session was to discuss the formal 

formation of a distinct working group to assemble a bibliography of 

documents and user training tools useful to NICs, LAN managers and end 

users° The Agenda, outlined below, was very ambitious for the time allotted. 

and consequently will extend into a follow-on WG session during the 

upcoming IETF-meeting at Stanford University, 25-28 July 89. 

AGENDA 

ATTENDEES 

- Form a distinct Working Group 

- Write Charter and Objectives 

- Select the Various Categories of Documents/Info to be Included 

- Determine "Plan of Attack" 

- Identify Existing Sources of Information 

- Discuss in Detail Biblio Format to be Adopted 

Karen Lo Bowers 

Tracy LaQuey 

Martyne Hallgren 

Joel Maloff 


Don Morris 

Ed Krol 

Tom Bajzek 

MINUTES 

Accomplishments: 

- Karen Roubicek and Tracy LaQuey were asked to co-chair this 

effort as a WG (tiger team) under USWG and graciously accepted. 

- A draft charter was drawn up and will be further revised and 

presented to the IETF Chairman for comment and approval prior 

to the Stanford IETF in July. 

- Some basic requirements were identified as essential to this 

effort: 

Contacting individuals directly for their participation and 

biblio inputs is probably the most effective way of 

obtaining information, though mailing lists and bulletins 

will still be employed° 

Each listing should contain some or all of the following 

information: 

* date of document 

* shelf life 

* where to obtain and format 

* abstract 

* limitations/caveats 

* version # 

-176-

Page 2 


Non-document sources of information could be included, 

such as videos, available user training workshops, etc: 

* MCI Video on Internetting 

* SIGUCCS/EDUCOM/MERIT Workshops 

* England Study (Source: Jim Sweeton) 

- Some documents have already been collected by Tracyo They are on 

emx.texas.edu. (The list of documents can be accessed by anonymous 

ftp. Cd to "user.wg/biblio" and the file is called "bibliography"° 

The actual documents thus far collected are in "user.wg/documents".) 

These documents have been placed in the following "tentative" 

categories: 

* Introductions to TCP/IP and the Internet 

* Technical TCP/IP Tutorials 

* Network Administrators Tutorials 

* Electronic Mail Tutorials 

* Electronic Mail Configuration Tutorials and 

Reference Materials for Network Managers 

* Directory Services Documents 

* Reference Materials 

Interim Activity Planned: 

Next Meeting: 

Within the next several weeks, Karen L. Bowers, Tracy LaQuey 

and Karen Roubicek will confer via a teleconference, finalize 

the Charter/Objectives, and outline the specific approach to 

be taken in assembling the bibliography. They will also 

discuss the official WG name to be adopted and determine if 

a mailing list separate from the us-wg mailing list is 

necessary or counter to active WG participation. 

This "biblio" WG will convene at Stanford. It is essential 

the USWG, NISI and "biblio" WG are scheduled ~t times 

independent of one another to ensure essential participation 

in all three forums. 

-i 7 7-

User Services 

Chairperson: 

Working Group 

Karen Bowers/NRI 

CHARTER 

Description 


The User Services Working Group will identify and address 

critical service requirements needed by "those people who 

help end users" (e.g. local net managers]l and develop tools 

and materials to aid in the productivity of end users. The 

purpose is to answer the needs of the lower levels (,) 

within this hierarchy: 


NATIONAL NETWORK 

NET MANAGERS (NSF, DCA, ETC.) 

NICs/NOCs 

REGIONAL NET MANAGERS 

LOCAL NET MANAGERS* 

END USERS* 

Assemble a non-static cadre of interested experts 

within an open forum to exchange user services 

information, to share problem-solving techniques, and 

to select critical projects to be undertaken on behalf 

of the local net manager and end user. 

o 

Select projects based on production-oriented criteria. 

The Proj ect (s) 

- must lend itself to accomplishment within a 

reasonable timeframe 

- must culminate in a measurable/quantifiable end 

result 

- must address user assistance needs = be user 

oriented 

- must yield products/tools designed to be both 

easily maintained and updated (with built in 

accountability) 

- must not duplicate efforts (This will be 

pre-empted by surveying exisitng resources.) 

o 

Determine the most appropriate approach to a respectiwa 

project (s): 

produce a totally new product 

enhance/improve/influence an existing resource 

table action for future consideration 

¯ 

Spin off various small WGs (tiger teams) to address 

very specific, short term projects (EX: NOC-Tools WG 

-178-

Charter 

Page 2 

and NISI WG). Once the. respective project(s) is completed, 

members of the tiger team(s) will reassemble within the USWG 

to participate in the identification of the next project(s! 

to be undertaken. 


Selection and completion of projects will occur on a 

continuous basis, with timelines established for each 

individual tiger team formed. 

-179- ¯

User Services 

Chairperson: 

Working Group 

Karen Bowers/NRI 

STATUS UPDATE 

lo Chairperson: Karen L. Bowers 


® 

WG Mailing List(s): US-WG@NNSC.NSF.NET and 

US-WG-REQUEST@NNSC.NSF.NET 

Date of Last Meeting: Cocoa Beach, Fl/April 11-12, 1989 

~ 

Date of Next Meeting: 

o NISI WG formation meeting 4 May 89 and Plenary/WG 

meeting Stanford University/ 25-28 .July 89 

o "Biblio" WG formation meeting 1 June 89 and Plenary/WG 

meeting Stanford University/ 25-28 July 89 

~ 


USWG Chairman to investigate Campus Awareness via meeting at 

NSF with D. Vanbelleghem, SIGUCCS et al and determine if 

USWG should get involved. 

0 


Formation of three WGs (tiger teams): NOC-Tools, NISI WG, 

and a bibliography WG (not yet named); refer to the CURRENT 

MEETING REPORT attached 

-180-

User Services Working Group 

Chairperson: Karen Bowers/NRI 


Reported by Karen Bowers 

AGENDA 

ATTENDEES 

Brief Intro of USWG (for new attendees) 

Planned USWG Organizational Structure 

Briefing on NOC-Tools WG (Bob Stine) 

Individual Briefings on AREAS FOR CONSIDERATION 

*Network Resources Handbook (T. LaQuey and K. Roubicek) 

*How to Set Up Campus NIC/NOC (T. LaQuey) 

*Bibliography of Documents Every NIC Should Have 

(M.Schoffstall and F. Perillo by e-mail) 

*Mailing List Management: Listserv (J. Sweeton) 

Other: USWG Review of DRAFT Outline for U of Texas’ 

Directory of Computer Networks (To LaQuey and USWG) 

Selection of Projects to be Undertaken 

Joyce K. Reynolds 

JKREYNOLDS@ISI.EDU 

Jim Sweeton 

SWEETON@Merit.Edu 


ROUBICEK@nnsc.nsf.net 

Mary Stahl 

STAHL@SRI-NIC.ARPA 

Jose J. Garcia-Luna 

garcia@sri-com 

Robert Stine 

stine@sparta.com 

Ole Jacobsen 

ole@csli.stanford.edu 

Tracy LaQuey 

tracy@emx.utexas.edu 

Don Morris 

morris@ncar.ucar.edu 

Scott Brim 

swb@devvax.tn.cornell.edu 


USC/ISI 

MERIT 

NNSC/BBN 

SRI/NIC 

SRI/NIC 

SPARTA 

ConneXions/ 

ACE 

UT Austin 

NCAR 

Cornell 

Stanford 


Elise Gerich 

MERIT/NSFNET 

epg@merit.edu 

Paul Love 

SDSC 

LOVEEP@SDS.SDSC.EDU 


NRI 


Rebecca Nitzan LLNL 

nitzan@nmfecc.llnl.gov 

213 822-1511 

313 936-3000 

617 873-3361 

415 859-4775 

415 859-5647 

703 448-0210 

415 941-3399 

512 471-3241 

303 497-1282 

607 255-8686 

415 723-2229 

313 936-3000 

619 534-5043 

703 620-8990 

415 422-9775 

-’181-

Page 2 


MINUTES 

After a brief review of our goals and charter the first item of 

discussion was the organizational structure of the USWG. Just as 

the members of the MIB WG have concluded, we too have determined 

that the USWG will be an umbrella organization from which smaller 

Working Groups (tigerteams) will be created to address short term 

projects. We have taken this one step further and have revised 

our Charter (provided above) to align with this structure and 

reflect the project management aspects of our WG activities. 

Bob.Stine presented a briefing on the newly formed NOC-Tools WG, 

one such tiger team. The thrust of NOC-Tools .is "to develop a 

catalog to assist network managers in the selection and 

acquisition of diagnostic and analytic tools (both hardware and 

software) for TCP/IP internets. This WG, co-chaired by Bob Stine 

(SPARTA) and Bob Enger (Contel), convened a separate WG session 

on Wednesday, 12 April 89; minutes from that meeting have been 

prepared and are available. 

Some of the AREAS FOR CONSIDERATION identified during our 

JAN/Austin,TX meeting (see Agenda) were researched during the 

spring quarter. Four of these were briefed by individual WG 

members and then were discussed at length by the USWG. 

As the discussions progressed it was evident that several 

distinct requirements were surfacing. The most dramatic 

realization was the need to define what "network information 

services" are and how those services overlap~differ at each level 

of the networking hierarchy (national/ regional/campus). During 

somewhat impromptu working lunch several USWG members concluded 

that what is needed is a requirements document addressing 

"network information services", to include re~irements at each 

level; basic/advanced/elite/(perhaps, private) services that 

could be made available; and how these services could be 

successfully interconnected as an Internet-wide Network. 

Information Service. The decision was made to hold a follow on 

exploratory meeting at NRI and invite a small group of NIC 

representatives. The purpose of the meeting is to define the 

general requirements for Internet information services and 

assemble that information into a network infoz~ation services 

requirements document. Tentative plans are for’ this requirements 

document to be produced by a small USWG tiger team, with review 

to be accomplished by the entire USWG and individual reviewers 

selected by the IETF Chairman. (This requirements document could 

conceivably be the precursor to the design of a Network 

Information Services Infrastructure to provide internet-wide 

network information services.) 

The second area identified for action is the creation of a 

bibliography useful to NICs, LAN managers, and end users. 

This will be an expansion of the work already done by 

-182-

Page 3 


Marty Schoffstall and Francine Perillo and will include documents 

which answer such questions as "what is the Internet" and "what 

services are available (mailinglists/enhanced services)" and will 

provide references t~ basic information such as "how to ftp", 

"how to use email" and "how to set up a campus NIC/NOC". This 

will include a reference to the NOC-Tools bibliography andother 

pertinent glossaries. Bibliotext was suggested as a useful format 

for setting up this bibliography° The bibliography and any 

related on-line documents will be installed in a repository. 

Tracy LaQuey volunteered to act as a temporary repository until 

the bibliography has been produced and procedures established to 

maintain/update the bibliography/on-line documents. A Video 

Teleconference will be held on/about 2 June to further address 

this project and better define the "boundaries" of what should be 

included in this document. 

Finally, the issue of "campus awareness" was raised and 

discussed. How can information be provided campus-wide to ensure 

colleges/universities are aware of I) what .connectivity currently 

exists on their respective campuses , and/or 2) how they can 

connect to the Internet and what connectivity provides them in 

terms of enhanced research capability and information exchange. 

This is an area currently being addressed by MERIT EDUCOM and 

SIGUCCS. The USWG needs to further investigate if we should/can 

play a role in this user education process; should we get 

involved in campus "road shows"? This will be discussed further 

at the next IETF plenary. 

AREAS FOR CONSIDERATION tabled at this time (to be addressed in 

the future): 

* Network Resources Directory 

* How to Set Up a Campus NIC/NOC 

* Mailing List Management 

* Consolidated Common End User Questions/Answers 

Other action items: 

Ensure Ed Krol (U of IL) and Charlie Catlett (NCSA) 

are invited to participate in the bibliography. (K. Bowers) 

Personally invite all key players (identified during our 

first meeting) to attend the Stanford meeting and/or 

be placed on the USWG mailing listo (J.K. Reynolds and 

K.Bowers) 

-183-

I I i I 

-184-

-18 5-

VI. Network Status Briefings 

and 

Technical Presentations 

-186-

Everything 

Presented 

You Ever Wanted to Know About OSPFIGP 

by John Moy 

This is a short introduction to the OSPF protocol° It has been 

developed during the past year in the OSPFIGP working group of 

the Internet Engineering Task Force. 

OSPF is an IP routing protocol, intended to be used internal to 

an Autonomous System. In internet terminology, such a routing 

protocol is called an Internal Gateway Protocol. The OSPF 

utilizes SPF-based routing technology in order to find the set of 

best paths to each internet destination. The "O" in OSPF stands 

for open; it is hoped that multiple vendors will implement the 

protocol and interoperate. 

OSPF has benefitted from the existing SPF routing technology. BBN 

first developed an SPF-based routing algorithm for the Arpanet in 

the 1970s. A paper by Radia Perlman ("Fault Tolerant Broadcast of 

Routing Information") introduced modifications to the SPF 

algorithm (e.g., the lollipop-shaped sequence space and the 

addition of a checksum field to links state advertisements) that 

enabled a reduction in the amount of routing traffic, and tlhe 

removal of the link-up waiting time. DEC’s IS-IS proposal 

introduced the concept of a Designated Router which generates a 

link state advertisement for transit networks. Finally, BBN did 

some work on area routing in an SPF-based system. 

Based on this foundation, the OSPF working group was formed in 

the spring of 1988. The major features of OSPF are as follows. 

There is fast response to topology changes with a minimum of 

routing traffic. When multiple best paths are available to a 

destination, they are disovered and used. Separate sets of paths 

are possible for each IP Type of Service. A network mask is 

passed with each advertised destination, enabling "variable 

length subnet masks". Externally derived routes (e.g., EGP 

routes) are tagged and distributed independently from internal 

OSPF routes. All OSPF routing protocol packet exchanges are 

authenticated. Finally, OSPF protocol traffic uses IP multicast 

instead of broadcast. 

OSPF also has an area routing scheme. This is very similar to the 

area routing developed by BBN. In OSPF area routing, routing 

inside any particular area is protected from outside 

interference. Also, the topology of the area is invisible from 

outside the area (similar to an IP subnetted network). Finally, 

the area ID is NOT encoded into the destination addresses. 

Quickly, this is how OSPF works. Link state advertisements 

describe the local topology. Each router originates a link state 

advertisement, called a "router links advertisement,’. This 

indicates the type, cost, and state of each of the router’s 

interfaces, together with what the interface .attaches to (a Page 

-188-

Page 2 

Everything 


transit network, stub network, or to another router via a 

point-to-point connection). Each transit network has a "network 

links advertisement" originated for it by the Designated Router.. 

This link state advertisement lists the set of routers attached 

to the transit network. Both of these link state advertisements 

are flooded throughout the routing domain° The collected set of 

advertisements forms the routing database. This database is 

identical in all nodes. From this database, each node calculates 

a shortest path tree, with itself as the root. This calculation 

yields the routing table. 

The presence of areas modifies the above somewhat. The algorithm 

executes in each area as above, calculating all the intra-area 

routes. Area border routers (those attached to more than one 

area) learn routes to destinations in other areas, and transmit 

this learned information to tlheir attached areas by means of 

"summary link advertisements". This third kind of link state 

advertisement is also flooded throughout a single area. 

All area border .routers must be attached to a single area: the 

"backbone". The backbone transmits the "inter-area" routing 

information (routes between areas). The backbone must 

connected; all areas are attached to the backbone, forming a star 

topology with the backbone as hub. Areas may dedicate some of 

their resources to the’ backbone; this enables the maintenance of 

backbone connectivity through the configuration of "virtual 

links". 

External routes are described by a fourth kind of link state 

advertisement, "AS external link advertisements". These, unlike 

the previous three advertisement types, are flooded throughout 

the entire Autonomous System instead of just throughout a single 

area. These advertisments are considered last when building a 

routing table. The following comparisons can be made between 

OSPF and the DEC IS-IS proposal. Both protocols are SPF-based, 

and as such use many of the same mechanisms (flooding, the 

shortest path calculation, etc.), just as any two Ford algorithms 

use many of the same mechanisms (broadcast of routing tables, 

etc.). The main differences between OSPF and the DEC proposal cna 

be broken .up into SPF differences, area.routing differences, and 

special IP considerations. 

The SPF differences include the following. OSPF ensures that a 

router’s routing database is synchronized before the router is 

allowed to forward data traffic. This guards against packet 

looping. OSPF has made the following routing traffic reductions: 

on a transit networks database synchronization occurs only over 

OSPF adjacencies (an o(n) problem rather than o(n**2)), 

attempt is made to sychronize link state advertisement ages, and 

external routes are specified each in a separate advertisement 

(allowing incremental updates). OSPF allows the specification 

-189-

Page 3 

Everything 


two types of external metric (one comparable to the link state 

metric, and the other larger than any link state path). Finally, 

OSPF has no special "link state confusion logic"; link state 

checksum conflicts are treated the same as sequence number 

conflicts. 

OSPF area routing looks much like the BBN area scheme, instead of 

the DEC IS-IS areas. The OSPF area ID is not part of the 

destination address. This allows the intelligent selection of 

exit/entry touters when routing to destination areas, and avoids 

the introduction of area partition repair logic (partitioned 

areas instead appear as two separate areas). The OSPF backbone is 

similar to the level two routing in the DEC IS-IS proposal. 

However, the OSPF backbone need not be physically connected, and 

may instead be connected by means of virtual links. 

Finally, OSPF is an IP routing protocol, while the DEC IS-IS 

is an ISO routing protocol. OSPF passes around native IP 

addresses, and provides explicit IP subnetting support. OSPF 

packet formats have been designed so that they can be efficiently 

parsed in an IP environment. The packet formats have also been 

designed so that IP fragmentation and assembly should not be 

necessary. Finally, OSPF should provide some experience with IP 

multicasto 

-190-

U 

| | ! ! 

-192-

I I i 

-193-

I I I l I I

0 

U 

I I i

-i96-

-i97-

0 

~llli 

0 

U 

0 

U 

0 1.1.1 ~ 

I I I 

I I I I 

-198-

-199-

"--" 4) 

0 0 

! ! ! ! 

-200-

0 

HI 

¯ 

ii 

! I 

-201-

I I i 

-202-

I 

i 

i i I I 

~n 

o 

u 

I I I 

-203-

The Open Routing Architecture 

Presented by Marianne Lepp 

The AS-AS routing architecture of the Open Routing Working Group 

has been designed for an Internet in which 10,000s of entities 

will participate in the routing. We expect that the bulk of the 

transit traffic will be carried by a small number of networks/ASs 

that are designated as fully transit. For ease of discussion, we 

call them "backbones". Other systems will carry a limited amount 

of transit traffic, dictated by policy agreements. Many others 

will act as stub systems carrying no transit traffic. 

We are designing for a reasonably simple topology with back-doors 

and short-cuts. We expect to be connecting heterogenous systems, 

where heterogenaity include gateways, protocols, and network 

technologies. 

The conceptual elements of the protocol are Routing Agents, 

Policy Agents, Forwarding Agents, User Agents, and Data 

Collection Agents. The Routing agents compute routes based on 

topology, policy, and type of service. They negotiate with the 

User Agent about whether a service can be provided or not. Tihe 

Policy Agent maintains the policy database, including the 

validation and sanity checking functions° The Forwarding Agent 

is what we currently think of as an IP-router. It accepts 

packets for forwarding. The User Agent may reside in the host 

or the host’s gateway and negotiates a route based on the 

application/user,s policy credentials. The Data Collection Agent 

supports the dynamic features of the protocol. 

The key features of the protocol are data reduction by 

recursively dividing the Internet into "areas", source routing, 

route set-up, and link attribute lists. The routing element is 

the way-station, which is the entrance point to Autonomous 

Regions. More information about the architecture itself can be 

found in the slides. 

-204-

-20 5-

.-207.-

-208-

. 

-209--

-210-

-211-

NASA Science I~nt~.=~r.net 

Milo S. Medin 

Sterling Software Corporation 

NASA Science lnternet Project Office 

NASA Ames Research Cen~er 

medin@nsipo.nasa, go v 

-212 -

2:: 

0 

1 

1 

-214-

CD 

0 

0 

0 

c~ 

r~ 

0 

Z 

0 

0 

0 

c- 

O 

O_ 

0 

0 

0 

0 

0 

-215--

E: 

~D 

Z 

< rj’) 

0 

0 

0 

0 

~D 

0 

< 

> 

Z 

-216-

0 

0 

c- 

O 

0 

0 

0 

0 

-217 -

-218- 

|"

4-- 

0 00 

0 

I 

-219-

÷ 

I 

c- 

0 

O~ 

c- 

(D 

c- 

O 

0 

-220-

Z 

O_ 

09 

0 

0 

0 

X 

-221-

Ez© 

lllll 

0 

-222-

0 

c~ 

c~ 

0 n- 

Z 

cO 

Z 

0 

0 

0 

0 

(D 

Z 

Z 

0 

0 

0 

0 

0 

.~- 

O_ 

c-’ 

0 

(D 

0 

0 

c- 

c- 

O 

0 

0 

.0 

0 

0 

Z 

-223-

~ U 

-224-

0 

© 

O 

Z 

CO 

Z 

Z 

0 

0 

0 

Z 

--225-

0 

0 

0 

0 

Z 

0 

~D c- 

O 

0 

0 

O_ 

0 

0 

0 

0 

n 

Z 

0 

0 

~D 

I 

Z 

-226-

0 

0 

O 

E 

0 

0 

-,227-

0I 

0 

c- 

II 

0 

0 

0 

I 

Z 

CO 

Z 

0 

Z 

-228-

NSN circuit utilization 

I | I1 

ill I 

, . ¯ ,.i ....... ,,~.~ ....... =, ................. 

l 11 lllll 

I ! II ! ~ .......... ........ 

Mar31 

Apt 05 Atx" 06 Apt 07 Apt 08 

Day 

jpiouhi 

Mar 31 Apt 01 Apr.02 Alx 03 A~ 04 A~ 0~ Apt 06 Apr 07 Apr 08 

Mar31 Alx 01 Apt 02 

Apt 6¢ 

¯ Apt 05 

. AI~ 06 AI~ 07 Apt 08 

-229- 

¯ 

¯ Day 

.. 

¯ 

.. 

,,

Z 

C~ 

Z 

Z 

0 

(-- 

0 

0 

O 

0 

0 

¯ 

¯ 

0 

(D. 

0 

0 

-230-

State of the Internet 

Presented by Zbigniew Opalka 

The number of networks in the Internet continues to grow. Since 

the beginning of the year the number of networks~ as reported by 

the Butterfly Mailbridges, has risen from approximately 550 to 

750 by April i. If this trend continues, as is expected, the 

Internet will reach 1,000 networks by the third quarter of this 

year. 

The Arpanet is steadily going away. Sites previously on the 

Arpanet are moving to various regional networks across the 

country. These regional nets are connected by the NSFNet; though 

connectivity to the Milnet is still provided by the Mailbridges. 

A new experimental terrestrial Wideband network is planned to 

provide connectivity between some sites currently attached to the 

Arpanet. The old satellite Wideband is being replaced by a 

network connected by T1 trunks, using a modified IEEE 802.6-type 

technology. The services provided by this network include 

datagram service (unannounced traffic), stream messages 

(resources reserved across the network), as well as 

multi-casting scheme using dynamic group addressing. 

The terrestrial Wideband network is composed of Butterfly 

Wideband Packet Switches (WPS) connected by T1 trunks. Attached 

to the WPSs are Butterfly Internet Gateways and Stream 

(ST-protocol based) Gateways. 

Mailbridges 

All six of the Butterfly Mailbridges are operational. They are 

currently supporting 210 neighbors (combined on both the Arpanet 

and Milnet). The LSI-II Mailbridges were decommissioned on March 

6, though the LSI-II EGP servers are still functional. It is 

highly recommended that anyone still using the LSI-II EGP se~-vers 

move over to the Butterflies as soon as possible. 

The Mailbridges are passing around 8 million packets per day. 

This figure varies greatly, anywhere between 6 and 13 million 

packets are sent per day. The drop rate across the Mailbridges 

for queuing reasons (not counting ttl expiration and 

unreachability) is insignificant (a total of 675 packets 

.00856 %). Average length of the packets passing through the 

Mailbridges is around 150 bytes. 

As stated earlier, the Mailbridges provide the connectivity 

between the Arpanet and Milnet. To enhance Milnet connectivity 

with the rest of the Internet, Ethernet interfaces will be added 

to the Butterfly Mailbridges first at Ames (west coast) and Mitre 

(east coast), then to the other Mailbridges. The Ethernets, 

Ames and Mitre, will also have attached to them an NSS, an NSFNet 

backbone switch. 

-232-

Page 2 

State of the Internet 

Two bugs have been discovered in the Mailbridges. The first 

deals with decrementing the TTL field in the IP header and then 

dropping the packet is the TTL drops to 0. The Mailbridges were 

decrementing the TTL as required. They would drop a packet if 

its TTL was 0 when it first entered the Mailbridge. The problem 

occurs when a Mailbridge decrements a TTL whose value was 1 when 

it entered the Mailbridge, the Mailbridge would check for 0; 

decrement the 1 (to 0) and forward the packet. The fix will 

be deployed in the next major release of the Mailbridge code, 

The second problem dealt with the EGP~ finite state machine (fsm) 

implementation. EGP, after neighbor acquisition, expects either 

Polls or Hellos to bring the EGP "link" up. The Mailbridges were 

expecting only Hellos after the initial neighbor acquisition, 

thereafter they would accept either Hellos or Polls. The code 

was fixed to accept both types of messages after neighbor 

acquisition and the fix has been deployed. 

--233-

-234-

-235-

-236-

-237-

Z 

-238-

-239-

-240-

-241- 

¯ ¯ ® ¯

© 

-242-

-243-

Growth of the Internet 

Presented by Mike St. Johns 

Based on the accumulated 5 years of data from BBNCC regarding 

advertised networks, the growth of the internet appears to be 

exponential. Previous graphs of the growth of network numbers 

have been plotted on linear axises, and we’ve long suspected the 

growth was exponential. I regraphed the data on a semi-log graph 

(linear X is time, log Y is number of networks) and then did 

fit on the data. The data line and the fit line appear to be 

pretty close. Unfortunately, I did not have access to tools 

which would have allowed a more formal statistical analysis of 

the data. 

The doubling period of the data is approximately 13-14 months. 

We should reach I000 networks by November of 1989, 8000 by March 

of 1993. If the trend continues, we could reach a million 

networks by sometime in 2000. 

Based on the 5 year trend, I actually believe we could have as 

many as 8000 networks by 1993. I think its too early to believe 

the year 2000 prediction, but it is settinq off some warning 

bells. 

-244-

0 

0 

0 

0 0 0 0 

0 (D 0 0 

(D 

(D 

0 

(3 

-245-

© 

© 

0 

-246-

-248-

DOE Energy Science Network 

Presented by Tony Hain 

ESnet is a service for DOE sponsored researchers providing 

enhanced communications facilities. Primary service is provided 

for the 5 Energy Research programs supported by the Office of 

Energy Research. Its goals are: 

Enhance Inter-program communications 

Enhance International collaborations 

Reduce costs 

Increase interconnectivity with other agency networks 

Increase performance 

Support OSI standards 

Current projects include: 

ITER program support for the US team 

MFEnet II upgrade 

Backbone Upgrades to T1 

X.25 backbone services for international access 

International and Interagency gateways 

At the January IETF I reported that we were in the midst of an 

audit by the DOE/IG. The IG report has been filed recommending 

that we leave both HEPnet and MFEnet as they are, "all of the 

users are happy with the services they have"° A formal rebuttal 

has been filed pointing out that current requirements cannot be 

met with existing services. 

ESnet underwent a program review March 6,7 by an outside panel of 

network specialists. The final report has not been submitted, but 

preliminary recommendations included: 

Centralize management of the DECnet with the lip backbone 

Drop IP encapsulation (required to switch X25 and IP on the same 

lines) plans 

Drop T1 multiplexing plans 

ESnet has undergone several significant changes since the January 

meeting. A decision was made to .drop X.25 as a native backbone 

service and allow DECnet phase IV in its place. This allowed 

procurement rather than development of the backbone routers. 

There are currently 19 sites identified for T1 service in 

calender ’89. Dual protocol routers are being procured for the T1 

backbone. ’ 

NASA and NSF backbone interconnects with ESnet are being planned. 

Implementation discussions will be held in the near future at 

MERIT. 

-250-

ilin 

-252-

In 

If 

in 

-253-

-254-

- 

[:: ¢:: 

cos 0 

LU 

-255-

¢~. 

0 

~0 

-256-

~D 

0 

C 

0 

E 

0 

c- 

~~D 

O 

E 

E 

00~D 

-257- 

~.u ~ 

C 

0O_ 

~D

C 

E ¢ E 

E 

-0 

0 

rO 

-2.58-

m~mmm| 

"0 

0 

(D 

0 

X 

mmmm 

0 

c- 

.< 

X 

E 

~m~ 

0 

0g 0 

c-- ~ 

0 CL 

0 (D 

CD (’} C~ 

U) C~) 

¯ 

0 (D 

0 * 

0 (D 

0 c" 

0 

0 

(D :3 

> 0 

-259-

-260-

An Interim 

Presented 

Routing Architecture 

by Russ Mundy 

The purpose of the Interconnectivity Working Group (IWG) 

to develop an interim Inter-Autonomous-System routing 

approach which will be available prior to the results of the 

work of Open Routing Working Group (ORWG). This 

necessary since the current Exterior Gateway Protocol (EGP) 

is inadequate and implementation of new ORWG solution will 

not be available for some time. 

TIME 

-> 

EGP 

Sufficient 

Open 

Routing 

Available 

--> 

Time-Frame for 

IWG Efforts 

There have been several previous meetings of the IWG and 

significant mailing list activity by the working group. 

Prior to the Austin IETF meeting, the IWG participants had 

primarily been individuals involved with managing National 

and/or Regional networks. During the Austin IETF, vendor 

representatives were asked to provide their views on the IWG 

approach. During the open meeting, the vendor 

representatives made general comments but were not negative 

about the IWG approach. Subsequent to the meeting, each of 

the vendor representatives contacted the IWG chairman and 

expressed concern about the commercial viability of making 

frequent protocol changes in their products which was being 

inferred by the timing of the IWG and the ORWG efforts. 

Generally, their constraints include interoperability of the 

new protocol with the installed operational base and their 

cycle for major software releases (usually only one per year 

for major protocol changes). 

As a result of the vendor inputs and the previous work of 

the IWG, the chairman drafted a Midterm Inter-Autonomous 

Routing Architecture (MIRA) that was distributed to the IWG 

mailing list prior to the Cocoa Beach IETF meeting. This 

draft paper became the basis for much of the discussion at 

this IETF meeting. 

The ORWG participated in the first portion of the IWG 

meeting. This joint meeting provided ORWG participants the 

-262-

Page 2 

An ~nterim Routing 

Architecture 

opportunity to review and comment on the IWG efforts. The 

general impression is that MIRA is a different solution to 

many of the problems being addressed by the ORWG but there 

are some areas where the MIRA approach could provide useful 

lessons for the ORWG. 

The approach described in the MIIRA paper provides improved 

prevention of loops, better fault detection and better 

support for the extensive connectivity between Networks and 

Autonomous-Systems. MIRA also seeks to minimize 

implementation difficulties for both vendors and network 

providers/operators. 

MIRA achieves many of these features by separation of 

functions. For example, route maintenance and packet 

forwarding is currently bundled in a single gateway. MIRA 

separates these functions into route server and border 

gateway. The separation also makes it feasible to provide a 

full Autonomous-System path that can be used to determine 

routes for packets. The route servers communicate with 

border gateways within its Autonomous-Systems as well as 

with route servers in other Autonomous-Systems. 

There are several current problems/difficulties that MIRA 

has not yet solved. Some of these include: the method for 

the initial bootstrap of a system is not clear; a method of 

providing reliable communications between route servers 

needs to be defined; the method of achieving consistency 

between the route servers within an Autonomous-System is not 

defined; and the method(s) route servers use to choose 

between routes is not defined. 

In addition, some of the ideas presented by the MIRA are 

being implemented by several participants of the IWG to gain 

experimental experience. Preliminary information from these 

implementations should be available for the July IETF 

meeting. 

-263-

-264-

%

Architectural Changes to the NSFNET 

Presented by Elise Gerich 

In the nine months that Merit has managed and operated the NSFNET 

backbone, traffic on the network has grown substanitially as 

havethe number of networks announced by the backbone. In the 

lastmonth, March 1989, we saw an approximately 30% increase in 

thetraffic on the backbone, and have over 450 nets connected via 

mid-level networks. 

Recognizing that the traffic was probably not going to decrease, 

and wanting to continue to offer good service to our users, MCI, 

IBM and Merit began to meet to plan an expansion of bandwidth for 

the backbone. As guidelines to our planning sessions, we 

established five primary objectives in redesigning the backbone. 

These objectives 

i) 

2) 

s) 

were: 

Eliminate the single tail circuits 

Provide a network diameter of 3 or less 

Provide a full T1 rate end-to-end bandwidth 

Be financially feasible 

Take initial steps toward DRS (Digital Reconfiguration 

Services) 

The first objective, eliminating the tail circuits, was identified 

as the most pressing need to address~ but we agreed it was 

desirable to fullfill all of the objectives° With these goals in 

mind, we came up with a new physical topology for the NSFNET 

backbone. 

Instead of 14 circuits connecting the 13 nodes, six of which were 

single tail circuits, the new topology consists of 19 circuits 

with three circuits terminating at each node except for MIDnet 

which has two circuits coming into it. This redesigned topology 

meets all of our objectives. 

The single tail circuits 

are eliminated. 

The network diameter is 3. 

Each node has circuits of full T1 rate bandwidth instead of 

the sub-Tl rate logical links that are currently provided on 

thebackbone. 

The redesign 

fits within our budget° 

And finally, this topology moves us toward DRS (Digital 

Reconfiguration Services). As you can see from the accompanying 

slide, we are moving toward an architecture where the circuits 

from each node feed into an MCI cloud. Within that cloud, 

-266-

Page 2 

Architechtural Changes to the NSFNET 

circuits may be allocated dynamically. We see this redesign as 

the first step toward implementing DRS. 

Along with this redesign of the topology, MCI has been upgrading 

some of its digital radio circuits with fiber. As we put the new 

physical network in place~ almost all of the circuits will be 

fiber, except for those circuits in the northwest and a few local 

loops. 

The implementation phases of the new design are already under 

way. The circuits are ordered, additional hardware/software is 

being installed on the NSSs, and preparation by the sites is in 

process. There are four primary phases in the migration to the 

new topology. 

Phase A which installs four additional circuits to the current 14 

circuit topology is tentatively scheduled to be in place by the 

beginning of June ’89. This phase addresses the need to 

eliminate the single tail circuits. 

The following three phases, B thru D, consist of installing 

and disconnecting pairs of circuits. One of our objectives in 

order to stay within budget is to eliminate the need for 

redundant circuit terminations at the local site. For instance, 

SDSC currently has four circuits terminating at its site, but 

only two of those circuits will. exist in the future backbone. So 

instead of installing an additional circuit at the local telco, 

we plan to roll one circuit out and another in. So at no time 

during the migration will any node exceed the final three local 

connections needed nor the existing number of connections. 

Furthermore, no nodes should become isolated during the 

installation. 

Phases B thru D are expected to be in place in July ’89. With 

the completion of those phases, we will have attained our 

objectives. 

In addition to redesigning the backbone technology, Merit has 

been addressing the need for direct peer network connections. 

Toward this end, we have met with Milo Medin, of NASA, and Mike 

St. Johns,of DCA, to design direct connections between the NSFNET 

backbone and NSN and Milnet. 

In the case of Milnet, we are in the process of deploying a 

configuration which we call a Split E-PSP (exterior packet 

switching processor). In this configuration,an NSS will have 

RT colocated on an Ethernet with a Butterfly-Mailbridge. This 

Split E-PSP will establish an EGP session with the Mailbridge. 

Then, the Split E-PSP has a serial connection to the rest of the 

NSS, and this provides a direct connection between the backbone 

and the DDN. 

-267-

Page 3 

Architectural Changes in NSFNET 

The Split E-PSP configuration will be deployed from both NSS 13 

(BARRNet) and NSS 9 (SURAnet), giving the NSFNET two connections 

to the DDN; one on the west coast and one on the east coast. We 

anticipate that at least one ofthe Mailbridges will be connected 

to the backbone by the end of May ’89. This date hinges on the 

availablity of T1 circuits. 

This Split E-PSP configuration at NSS 13 will also provide a 

direct connection to the NSN (NASA Science Net). Not only will 

the NSS EGP peer with the mailbridge, but also with a NSN-router. 

Milo Medin has also been negotiating with Jack Hahn at SURAnet to 

establish a SURAnet/NSN connection at NSS 9. If all goes well, 

NSFNET should have an east and west direct connection to both NSN 

and the Milnet. 

The NSFNET backbone announces approximately 60 international 

networks. Most of these announcements are received via a 

standard NSS configuration, but we have implemented an EGP 

session via a serial link with CNUSC in Montpellier, France. 

This configuration is described on one of the accompanying 

slides. Currently the lihk between NSS 10(CNSF/NYSERnet) and 

CNUSC is a 56 Kbps Satellite link, but we are planning to upgrade 

this to T1 via TAT8. 

Merit is pleased to announce the above architectural changes to 

the NSFNET backbone. However, this is just a beginning. We have 

recently deployed and made available SNMP. We continue to 

explore further changes and enhancements to NSFNET, such as ISO 

CLNP support, T3 upgrade, and possibly Xo25 support. These are 

just a few of the next steps for NSFNET. 

-268-

Physical NSFNET Topology 

Clrcles contain NSS numbor 

-269- 

Pf~p~,ed by NSFNET..lnfo@medt.e

Million Packets per Month 

NSFNET Trafl]c 

into/out-of the backbone 

70O 

¯ 

¯ o 

¯ 

¯ : ° 

..: ..... ~ ..... ¯ ..... ." ..... 

..~ ..... .~ ..... :. ..... .. ..... 

¯ 

¯ ". ¯ : : 

50O 

.. .. . 

.. 

: 

.. 

." 

¯ 

: 

: 

: : 

3OO 

¯ 

: ." - 

~ : - 

: 

." . 

: 

¯ .: ..... ; .... 

." . 

¯ 

200 

100 

8/87 9/87 10/87 11187 12187 1188 2/88 3188 

4/88’-~/88 6/88 7/88 8/88 9188 10/88 11/88 12/88 01/89 02/89 

-270-

Net Number Count 

Network Number Counts 

Marcl~ 1989 

Internet-wide network number count 

600 ........................................................................................................................ 

NSFNET directly attached via mid.level networks 

200 .......................................................................................................................... 

i 

¯ 

¯ 

¯ . 

...... 

.. 

... 

1 March 8 March 16 March 24 March 

Month of March 

-271-

Primary Objectives 

Eliminate the tail circuits (Redundancy) 

Maintain network diameter of 3 or less 

Provide each node with bandwidth of full T1 

Be financially 

feasible 

Take initial 

steps toward DRS 

1/18/89 epg 

-272-

NSFNET DRS .Application 

slt~ 

MCI DXC 

MCI DXC 

Tel~ 

POP 

POP 

-273-°

Initial 

NSFNET deployment: 

New architecture: 

Logical 

Topology 

Physical 

Topology 

Logiezll 

Topology 

(physical) 

MCI Network 

Infrastructure 

(physical) 

MCI Network 

Infrastructure 

-274-

Utilization in Percent 

NSFNET Logical Link Utilizalion 

]Peak: vs. Average 

19 

18 

17 

15 

14 

13 

12 

11 

10 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 

NSFNET Logical Links 

-275-

i 

ii 

.i

NSFNET Logical Link Utilization 

Peak vs. Average 

Utilization in Percent " 

20 [ .... ,. ....". .....: .....: .....: ....: .... ’. ....’. ....: .....: .....: .....: .....: ....: .... ’. ....: .... : .....: .....: ....: .... ’. ....’. ....: 

141 .... l’"l’"l’": ..... :".... 

I I I !\ 

13 ............ : ..... 

i i .......................... "--i.... :::::::::::::::::::::: 

10 .... ~ ............................. 

"...: .....i. ....i .....";....~.... : .... ~ .... ~ .....: .....:’....~.... : .... "...."." 

9 .... ~ ..................................... 

: ! ! i i i ~ i ! ! i : : : 

./ ! i i : . . : 

~~ ......."..’..r’..~~ 

.... .... .... :"..~-’~~.~:~~~~ 

........................................... 

:: :: ~ ~ ~ ~ ~ ~ ~ ~ ! + .......... ~ ~ i :............. 

1~ .... i ....:.....’.....~ .... 

l ! i i i ! i ! i i i i ! i i : : : : ~. :" .,,.";’--’~ :. 

1 2 3 4 5 6 7 8 9 10, 11 12 13 14 15 16 17 18 19 20 21 22 23 


-277-

New NSFNET Backbone 

Circles contain NSS number (1-4 end 4$-46 ere test nodes) 

-279- 

Prepared by NSFNET-Info@medt.edu at Thu Apr 6 16:57:091989 

netm¢o.-1.5 program by Bri;an Reid, madata from Wodd Data Bank II 

Lambert ConformaJ Projection [44"N,33"N], Map center: [40"N, 96" 30"W] 

Image resolution 300/in., stroke limit 1 ~ixels

Utilization in Percent 

20 

NSFNET Logical Link Utilization 

Peak vs. Average 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 


-280-

.0 

¯ 

-281-

-282-

--283- .

-284-

NEW TOPOLOGY 

" Fatter " pipes for packet switching 

No multiplexing and demultiplexing at sub T1 rates 

Clear channel T1 

Greater redundancy 

. No single tail circuit sites 

. No articulation points 

Optimized for MCI infrastructure 

. MCI redundancy 

. Optimum MCI routes 

Greater degree of connectivity 

3.07 v/s 2.15 

-285-

Planned 

NSFNET/NSN/DDN connection 

at NASA Ames 

NSS # 13 

L/ 

Possible EGP sessions: 

. NSS - Mailbridge 

. NSS - NSN Router 

. NSN Router- Mailbridge 

BARRNET connection 

TI llnk 

(Stanford - Ames) 

DSUICSU 

Split E-PSP 

Butterfly- 

Mailbridge 

I 

7 March 1989, HWB 

-286-

Planned NSFNET/NSN/DDN connecti~m at 

the University of Maryland 

Possible EGP sessions: 

NSS #9 

. NSS -Mailbridge 

. NSS - NSN Router 

I 

II 

connection 

"N~ "N~College Park - McLean) 

i 

[ NSN.Router 

L.~ ~" DSUICSU 

Split E.PSP 

NASA 

Science Net 

Mitre 

Butterfly- 

Mailbridge 

Arpanet 

7 March 1989, HWB 

-287-

Recently deployed: 

¯ SNMP 

Planned: 

¯ ISO CLNP support 

Proposed: 

. T3 upgrade in 1990 

Being considered: 

. X.25 support 

¯ , 

10 April ~989, H~VB 

-288-

Nifty NSFNET Stats, using NNStat 

Presented by Elise Gerich 

Reported by Dave Katz 

When the National Science Foundation sent out the solicitation 

~for the NSFNET in 1987, one of the charges was to provide 

continuous information gathering relative to the activity on the 

network and distribute the resulting data in electronic and 

hardcopy form. 

This is being accomplished with the use of NNStat (NSF Net 

STATistics), a package written with NSF funding by Bob Braden and 

Annette DeSchon at the Information Sciences Institute at USC. 

This package was originally coded .to run in a Sun workstation 

attached to an Ethernet; changes were made to it and to the BSD 

4.3 kernel so that it would run on an IBM IRT PC attached to a 

token ring network. 

The NNStat set of programs and utilities provide a flexible 

method for gathering traffic statistics, querying them 

interactively, and remotely collecting them for later analysis. 

There are three major components 

to the package: 

Monitoring--"Statspy,, listens to the traffic on a network 

and builds statistical objects based on what it hears 

Query--"Rspy’, allows remote interactive queries to Statspy, 

providing the capability of dynamically altering its 

configuration and displaying gathered data 

Collection--"Collect,, remotely retriew~s statistics from 

Statspy and logs it to disk for later processing 

Installation 

A cooperative effort was undertaken to install NNStat in the 

backbone. First of all, the NNStat application itself was ported 

to the IBM RT by Merit Internet Engineering staff. This entailed 

minor modifications to run in the RT environment, as well as the 

addition of a few features, the most notable of which is a 

security enhancement that restricts access to statistics data to 

a small number of machines. 

The Berkeley 4.3 "Packet Filter" was installed in the NSS kernel 

by Merit IE staff to provide an application interface to the raw 

packet stream. This package was optimized and enhanced to meet 

the needs of NNStat. 

The IBM Token Ring adaptor driver software was modified by Merit 

IE staff to support the Packet Filter interface and the 

"promiscuous" reception of packets. 

-290- --

Page 2 

Nifty NSFNET Stats, using NNStato 

A set of Read Only Memory (ROM) chips were obtained through the 

courtesy of Texas Instruments that allow the Token Ring adaptor 

to receive all token ring traffic. These chips were duplicated 

en masse by members of the Network Operations Center staff, and 

were installed by IBM’s se~ice representatives at each of the 

backbone sites. 

Staff in the Merit Information Services group continue to work on 

a database into which the raw statistics information is placed. 

This database will provide a flexible way of retrieving subsets 

of sample data as well as aggregations of data. It will be 

possible to convert the data to graphical representations as 

well. 

Configuration 

A dedicated IBM RT in each NSS is used to run Statspy. The RT 

receives all data on the NSS token ring, which has a number of 

desirable characteristics: 

all user data traverses the token ring 

both transit traffic and traffic to/from the local NSS are 

present 

intra-backbone traffic (such as routing protocol traffic) 

present 

no local site (intra-regional) traffic is visible 

An IBM RT at the NSFNET NOC in Ann Arbor, running Collect, 

periodically calls out to each of the backbone statistics 

gatherers, logs the values of their statistical objects to disk, 

and clears the objects. The logs are transferred to the NSFNET IS 

mainframe. Once Berkeley Socket support is available on the IS 

mainframe, the Collect application will be ported to run there, 

thus eliminating staging the data on an RTo 

On the mainframe, the raw statistics data is processed and loaded 

into a SPIRES database. Ancillary data, such as the mappings 

between network numbers and Autonomous System numbers, are added 

to the database as well. The database will allow flexible data 

retrieval by location, time, and other parameters. The raw data 

are archived to tape. 

The gathering of statistics data has a negligible impact on 

network performance. The CPU-intensive parts of the process are 

performed on dedicated machines that are not involved in the 

switching of packets, and the data collected from the backbone is 

~odest in volume compared to the traffic levels. 

Data Collected 

Approximately i0 million bytes of raw statistics data are 

collected daily. The bulk of the data are source/destination 

-291-

Page 3 

Nifty NSFNET Stats, using NNStat 

network number pairs. Other data collected include the token 

ring packet switching rate, the distribution of well-known TCP 

and UDP ports, and the distribution of packet sizes. Data is 

collected with a granularity of fifteen minutes. 

The accompanying slides contain the followinq: 

A sample configuration for Statspy. This configuration 

defines the statistical objects to be built, as well as the 

access restrictions in effect. 

Sample output from Rspy. This output corresponds to the 

configuration shown previously. The verbose logs from 

Collect are nearly identical. Terse logs from Collect 

contain th~ same information but in considerably less disk 

space. 

Sample graphs. These graphs were put together quickly using 

relatively small amounts of data for illustrative purposes, 

although the data is real. 

-292-

-293-

-294-

-295-

-296-

oO 

Z 

o9 

Z 

E 

- 0 

(’6AV) puo0~9 .~ed s~e~tOgd

CO 

Z 

Z 

II 

0 

HI 

II 

COO 

! 

! 

II 

on 

II 

I 

IO 

i II 

0 

,4ouenbe.~.-I

¯ 

II 

,4ouenbeJ-.I

Z 

0 

¯ ~z _o 

!-- 

,4ouenbe.~

Inter Autonomous System Routing Alternatives 

Presented by Yakov Rekhter/IBM 

Since Inter-Domain Routing is not going to be available in 

the near future, and since using EGP as an inter-Autonomous 

system protocol becomes more and more unfeasible, work 

should be done on the EGP replacement. This is largely due 

to an increase in complexity for connectivity between 

Administrative Domains. 

The IETF IWG group is concentrating on providing this 

intermediate solution for EGP replacement. Most of the 

members of IWG are deeply involved with NSFNET as well. 

Initially the basis for the next Inter-AD routing 

architecture seemed to be satisfyable by means of the EGP3 

protocol. However, during the discussions in the working 

group it became obvious that the EGP3, as proposed, would 

only satisfy reachability, but not routing requirements. 

Using some ideas from the IWG, IBM and CISCO came up with a 

draft proposal for the EGP replacement - The Border Gateway 

Protocol (BGP). BGP does not impose any requirements on the 

IGP within an Administraive Domain or Routing Domain. 

IBM and CISCO already have an initial implementation of this 

protocol. Testing is done between NSS-I (at Merit) and CISCO 

router (either at Merit or at CISCO). This is done by Jacob 

Rekhter (IBM, implementing the NSS code), Kirk Lougheed 

(Cisco, implementing the Cisco version) and Jessica 

(Merit, testing and verifying interoperability). 

Jeff Honig at the Cornell University Theory Center is 

working on a public domain BGP implementation (as part of 

GATED) 

A draft paper on BGP is available. 

hwb@merit.edu. 

Send mail to 

We have to make very rapid progress with BGP. It is 

currently in an experimental stage, but should be moved to 

an operational stage once the architecture proves feasible° 

-302- 

..

--303-

-304- 

~ .

-305-

Requiem for the Arpanet 

Vinton G. Cerf 

-308-

Requiem 

for the ARPANET 

Vint Cerf 

Like distant islands sundered by the sea, 

We had no sense of one community. 

We lived and worked apart and rarely knew 

that others searched with us for knowledge, too. 

Distant ARPA spurred us in ourquest 

and for our part we worked and put to test 

new thoughts and theories of computing art; 

we deemed it science not, but made a start. 

Each time a new machine was built and sold, 

we’d add it to our list of needs and told 

our source of funds "Alas! Our knowledge loom 

will halt ’til it’s in our computer room." 

Even ARPA with its vast resources 

could not buy us all new teams of horses 

every year with which to run the race. 

Not even ARPA could keep up that pace! 

But, could these new resourcesonot be shared? 

Let links be built; machines and men be paired! 

Let distance be no barrier! They set 

that goal: design and build the ARPANET! 

As so it was in nineteen sixty-nine, 

a net arose of BBN design. 

No circuit switches these, nor net complete 

but something new: a packet switching fleet. 

The first node occupied UCLA 

where protocols and measurement would play 

a major role in shaping how the net 

would rise to meet the challenges unmet. 

The second node, the NIC, was soon installed. 

The Network Info Center, it was called. 

Hosts and users, services were touted: 

to the NIC was network knowledge routed. 

Nodes three and four soon joined the other two: 

UCSB and UTAH come on cue. 

To monitor it all around the clock 

at BBN, they built and ran the NOC. 

A protocol was built for host-to-host 

communication° Running coast-to-coast, 

below the TELNET and the FTP, 

we called this protocolthe NCP. 

The big surprise for most of us, although 

some said they guessed, was another protocol 

used more than all the rest to shuttle 

mail in content flaming or most subtle. 

-310-

When we convened the first I Triple C, 

the ARPANET was shown for all to see. 

A watershed in packet switching art, 

this demo played an overwhelming part. 

Within three years the net had grown so large 

we had to ask that DCA take charge 

to operate a system guaranteed 

for R&D and military need° 

Exploring other packet switching modes, 

we built the first spread spectrum mobile nodes° 

The Packet Radio, the mobile net, 

worked on the ground and even in a jet. 

Deployed at SAC and Eighteenth Airborne Corps, 

the Packet Radio unlocked the door 

to what we now know as the Internet. 

The driver for it all was PRNET. 

The Packet Satellite, another new 

technique, was added to the net milieu. 

And then to shed more light upon the dark, 

there came the Etherne~ from Xerox PARCo 

To these we added yet another thing 

from MIT: a local token ring. 

We saw the local net techniques compound 

until the list could easily confound. 

The Internet foundation thus was laido 

Its protocols from many sources made. 

And through it all the ARPANET grew more; 

It was, for Internet, the central core° 

The hardware of the net was changing, too. 

The Honeywell was first, and then the SUE, 

which forms the heart of Pluribus today 

though where this platform sits one cannot say. 

The next big change was called the MBB. 

It emulated Honeywell, you see, 

so one by one they modified each node, 

by means of closely written microcode. 

Now known as 30 prefixed with a C, 

these nodes are everywhere from A to Zo 

The European MINET too was full 

of nodes like these from Mons to Instanbul. 

The second Autodin was long desired 

but once accepted instantly expired. 

Then to the rescue rode the ARPANET! 

And soon the MILNET by its side was set. 

-311-

By Nineteen-Eighty DoD opined 

its data networks soon must be aligned 

with Internetwork protocols, to wit: 

by Eighty-Three the TCP was IT! 

Soon every host that sat on ARPANET 

became a gateway to a local net. 

By Eighty-Six new long haul nets appeared 

as ARPANET its second decade neared° 

The NSFNET and its entourage 

began a stately national dressage 

and soon was galloping at T1 speed 

outdistancing its aging peer indeed. 

And so, at last, we knew its course had run, 

our faithful servant, ARPANET, was done. 

It was the first, and being first, was best, 

but now we lay it down to ever rest. 

Now pause with me a moment, shed some tears. 

For auld lang syne, for love, for years and years 

of faithful service, duty done, I weep. 

Lay down thy packet, now, O friend, and sleep° 

-312-

--313-

IU 

Z 

_ 

: 

-314-

-315-

-316-

0 

F-- 

uJ 

Z 

-317 -

Mailbridge Access Control 

Marianne 

Lepp 

-319-

-321-

-.322- 

¯ ¯ ¯

-323-

LU .,J 

0 

I,,.,, 

0 

r,- 

I- 

Z 

0 

0 

0

¯ ¯ ¯

The DCA TCP/IP Certification Program 

Presented by Martin Gross/DCA/DCEC 

In an effort to ensure compliance with its Military Standard Higih 

Level Data Communications Protocols (IP,TCP,FTP,SMTP,TELNET) and 

increase the probability of interoperability in its diverse 

multi-vendor environment, the Department of Defense (DoD) has 

initiated a program to certify vendor implementations of these 

products. As Executive Agent for the DoD Data Communications 

Protocols, the Defense Communications Agency (DCA) has been 

tasked with implementing this program. 

The policy for high level protocol conformance testing was 

established in a memorandum from the ~Assistant Secretary of 

Defense for Command, Control, communications and Intelligence 

dated 26 August 1988. The memorandum mandates conformance testing 

on all new contracts executed after 1 June 1989. Products 

procured under contract must be tested by a National Institute of 

Standards and Technology (NIST) accredited laboratory prior 

operational use on any DoD network. The memorandum also 

establishes a Qualified Products List which will be ~maintained by 

DCA. For a product to be placed on the Qualified Products List, 

acceptable tests results must be presented to DCA from an 

accredited laboratory which is independent of the vendor. 

DCA started an in-house testing program for DDN X.25 in 1983. Due 

to limited resources however, this program could not be continued 

in-house nor could a high level protocol test program be 

developed in the same manner. For this reason DCA turned to tlhe 

National Voluntary Laboratory Accreditation Program (NVLAP) run 

by NIST. Under NVLAP, laboratories are recognized and accredited 

to perform specific testing services aimed at evaluating products 

to determine if they meet applicable standards. As the program’s 

name specifies, this is a voluntary program and NVLAP 

accreditation does not imply the certification of products or 

test data. In July 1988, DCA requested that NIST establish a 

NVLAP for the DoD Protocols (DDN X.25 and the five High Leve3~ 

Protocols). Formal establishment of the program was announced in 

the Federal Register on 21 July 1988. The X.25 Program was 

established first and there are currently three accredited 

laboratories. The NVLAP for the High Level Protocols is 

now being developed. 

The NVLAP Handbook for the High Level Protocols which presents 

the operational and technical requirements for an accredited 

laboratory was published in draft form on 22 March 1989. The 

document was mailed to all those who replied to the Federal 

Register Announcement and was open to public comment until the 

14 April. Laboratory applications are now being accepted by NIST 

and the first laboratory will be accredited by the middle of 

June. It is expected that there will be a minimum of three 

accredited laboratories. 

-327-

Page 2 

The DCA TCP/IP Certification 

Program 

The laboratories will be required to use the [)CA Upper Level 

Protocol Test System to perform the tes°ting service. The system 

was developed under DCA contract to provide a standard testing 

capability for the DoD High Level Protocols. The system tests 

protocol functionality including; upper layer interfaces, 

validity of outputs, and input error handling. (See Connexions 

Volume 2, Number 8 for further details) The test system operates 

on a VAX* cpu running Ultrix* 1.1 and is publicly available from 

the Nationa~ Technical Information Service. The system has been 

in use since December of 1987 and is currently in use by ten 

organizations for in-house testing. 

To clarify testing policies and provide guidance to vendors, DCA 

will publish a DoD High Level Protocols Testing Circular. The 

circular will establish specific testing policies relating to the 

testing of products across hardware lines and the retesting of 

modified products. The circular will also establish the procedure 

for placement of products on the Qualified Products List. The DoD 

Protocol Conformance Testing Profile will also be included in the 

circular. This Profile establishes the set of mandatory features 

that must be implemented in each protocol. It also indicates 

those features which are optional. This Profile has been approved 

by the DoD’s Protocol Standards Steering Group but is still 

available from DCA for public co~mment. The testing circular will 

be published in draft form by 1 June. 

To help vendors prepare their products for laboratory 

certification, DCA has installed a test system that can be used 

by vendors. This system will be available for the next nine 

months on a first come first served basis. The system is 

accesible through the Internet or a dial-up link and is available 

for self testing with no on-line support~ 3information is provided 

below on how to obtain further information on this program. 

Comments or questions relating to protocol testing can be 

addressed to: 

Martin Gross 

DCA Code R640 

1860 Wiehle Ave. 

Reston, VA 22090-5500 or 

by email: martin@edn-unix.dca.mil or martin@protolaba.dca.mil. 

For NVLAP information or documents contact: Jeff Horlick, NVLAP, 

NIST, Bldg 411, Gaithersburg, MD 20899, (301)975-4016. 

For the DCA Upper Level Protocol Test System and Documents 

contact: 

National Technical Information Service 

Springfield, VA 22161 

(703)487-4807. Product #AD-A204-558. 

*VAX and Ultrix are Trademarks of the Digital Equipment 

Corporation. 

-328-

W 

Z 

-329-

-330,-

d 

~ 0 0 

0 

0 

0 

0 

-331-

0 

0 ~D X 

-332-

0 

0 

0 

cco 

am 

0 

nnmlm 

"E 

0 0 

0 

0 

O 

-334-

¯ 

n 

0 

0 

¯ ¯ ¯ O

~ 

0 

0 

Z 

-338-

0 

0 

0

-336-

IJJ 

0 

._z 

o o 

-339-

This notk~e is i.~ed in sccordance 

~ri~ | 7.17 of ~e ~ ~u~s (15 

C~ P~ 7),, ~tabll~h~t of 

p~am for ~t~ee ~t test ~e 

computer md~’l ~m~t=~ of 

co~i~fions 

Depa~ent 

pm~is ~ ~ the 

of ~e~ ~o~ a 

by the Defense Co~~b~ 

Aaency. A F~e~ ~~ no~ 

a~ouncin8 the Rquesl tot Me ~l~ols 

~ wa. pub~bed oo D~m~r 30 1~ 

(~ ~ 45~~). Co~en~ ~ceived 

in response to ~e a~o~cement were 

reviewed by the De(ense 

~~cabo~ 

wbo~ ~tor, 

~~ Center 

We~ P. Hello. 

has con~ ~at ~ we~ no v~Iid 

reaso~ p~sented in ~e comment 

[~en to ~tvent establishment of the 

~tocols ~ and ~eR~om requested 

¯ e Nab~ ~au of St~dard. to 

P~

-341-

Header Compression 

for TCP/IP Datagrams 

Van Jacobson 

Lawrence Berkeley Laboratory 

IETF 

Cocoa Beach, FL 

April 11-14, 1989 

-343-

c" 

E 

C) 

0 

0 

> 

0 

> 

o 

E 

E 

o 

~- o 

-345-

0 

ii ~ 

-346-

Data Throughput (% of line speed) 

5O 60 

70 80 

j 

2400 bps 

% % 

%% 

9600 bps 

19200 bps t 

90 

l 

I 

100 

! 

t 

I 

I 

I!I 

-347-

I IIII 

..~ 

_.I 

< 

--348-

| 

¯ 

o 

,© 

| 

, ~. 

-349-

-350 -

A A A A A 

¯ ¯ ¯ ¯ ¯ ¯ ¯ 

¯ A . A ¯ A . A 

A ¯ A (~ A ¯ A ¯ 

-351-

-35~-

4...3 4J 

4-.-) 4J 

A 

A 

¯ e ¯ ¯ 

-353-

e ~ e 

0 

¯ ~ ¯ CD ¯ ed’) ¯ O9 

A A A A A 

-354--

Compression effectiveness - client side of telnet 

Header size (bytes) 

c- 

o~ 

0 

0 

I 

-356-

~--" 0 0 0 0 0 

v-- 

v- LO CO 

CO 0 r...D 0 0 0 

03 CO ’~" ~-- 0 CO 

v- 

O0 o 

~~Oxx 

E .x 

Compression effectiveness - client side of teinet 

o/ 

10 20 

Header size (bytes) 

3O 40

VII. Papers Distributed at IETF 

Five documents were made available at the April IETF meeting. Four are enclosed. The 

remaining document entitled ."Inter- domain Intermediate Systems Routing", January 1989 

Draft Technical Report, ECMA TRBSK, Report # ECMA/TC32-TG10/89/... is not enclosed. 

This document was authored by the European Computer Manufacturers Association "to state 

the ECMA position with regard to Inter-Domain Routing; to serve as a vehicle for 

influencing decisions in other standard arenas; and to formalize the work carried out by 

ECMA". Inquiries concerning this particular document should be directed to Doug 

Montgomery/301-975-3630 or Tassos Nakassis/301-975-3632. 

-359-

INTERNET CLUSTER ADDRESSING SCHEME AND ITS APPLICATION TO PUBLIC DATA NETWORKS 

Carl-Herbert 

Rokit~nsky 

Fern University of Hagen, 

D-5860 !serlohn, FRG 

roki@A.ISI.EDU 

The DARPA Internet protocol suite (TCP/IP, FTP, SMTP, TELNET, etc.) has developed 

into de facto industry standard for heterogeneous packet-switching 

computer networks. However, it seems that the I~ternet community has neglected 

the highly important public data network community so far. Thus, the 

current Internet gateway architecture does not provide dynamic algorithms to 

route !nternet datagrams through public data networks. 

In this paper a new concept of an addressing scheme is presented, in which a 

set of Internet networks is associated to an !nternet cluster. Since this 

"Cluster Addressing Scheme" is of interest especially for wide-area networks 

(whose structure should be visible to the outside world for routing decisions), 

the application of the cluster addressing scheme to the system of 

X.25 public data networks is proposed. In addition the use of an addressmask 

(called "Cluster-Mask") for routing decisions within the cluster 

discussed. Finally, due to the fact that VAN-gateways interconnect a .data- 

.gram-oriented Internet world and a connection-oriented X.25 world, a new 

use of the IP Source Route option is proposed. The presented concept of the 

cluster addressing scheme provides a basis for the routing of Internet datagrams 

through X.25 public data networks and would therefore allow worldwide 

interoperation between the many local-area networks in various countries now 

using DARPA Internet TCP/iP protocols. 

INTRODUCTION 

The DARPA Internet system presently includes 

several thousand hosts connected 

to over 450 networks using over 250 gateways. 

It provides packet transport by 

means of a datagram service for hosts 

subscribing to the DARPA !nternet protocol 

suite. A host may be connected to 

more than one network. Each datagram contains 

a 32-bit source and destination 

address and travels independently through 

the Internet. Datagrams can be sent over 

different routes and they can be delivered 

out of order; if they get lost or 

contain errors, duplicate datagrams are 

retransmitted. 

The basic datagram protocol is the Internet 

Protocol (IP) [l]. Error reporting, 

flow control, first-hop gateway redirection 

and other control functions are provided 

by the Internet Control Message 

Protocol (ICMP) [2]. The Transmission 

Control ?rotocol (TCP) provides reliable 

end-to-end data stream service. A much 

simpler transport protocol than TCP is 

the User Datagram Protocol (UDP). All 

user level prot:ocols above use either 

TCP/~P (e.g. FTP~ TELNET, SMTP) or UDP/IP 

(e.g. NAMESERVER) as the basic packet 

transport mechanism. Due to their widespread 

implementation under various operating 

systems these protocols have developed 

into de facto industry standards for 

heterogeneous ]jacket-switching computer 

networks. 

The Internet model includes constituent 

networks, called local networks, to distinguish 

them from the internet system as 

a whole. These local networks are connected 

together by means of Internet 

gateways. Each gateway is connected to 

two or more networks by a physical interface 

and has an address on each of the 

local nets between which it provides datagram 

transport service. Gateways belonging 

to different gateway systems 

("autonomous systems") might use different 

intra-system routing mechanisms. In 

order to maintain the routing tables, an 

This work was carried out at the German Aerospace Research Establishment (DFVLR) 

part of the ~n%ernet research project and is ~on~inued a~ the Fern University of Hagen. 

-361-

interior gateway protocol like the Gateway-Gateway 

Protocol (GGP) [3]

Assume that direct connections can be established 

between the gateways and hosts 

attached to network W. 

According to the Internet routing model, 

packets from host HA to both HWI and HW2 

will be routed via gateway GAW (minimum 

hop count). 

If W is a homogeneous network (i.e. delays, 

costs, quality of links, etc. between 

hosts/gateways on W do not differ 

very much) then routing through network 

will be probably worse in any case. . 

Now assume that network W is inhomogeneous. 

For example the costs for a connection 

between GAW and HW2 are three times 

higher than between GBW and HW2. in this 

case it might be reasonable to route 

packets from HA to HW2 through network B 

via gateway GBW instead via GAW. Now, for 

[outing decisions, the internal structure 

of network W would be of interest even 

outside it. However the current Internet 

gateway architecture does not provide any 

algorithms for this situation (due to 

"network-centric" routing), except that 

user on HA could specify GBW explicitly 

in an IP source route option. 

Note, that dividing network W into several 

subnets according to the internal 

structure of W would have no external 

effects, because it is invisible to the 

outside world as mentioned above. Therefore 

packets would still be routed from 

HA to HW2 via GAW and not through network 

B. 

Another idea would be to assign different 

!nternet network numbers to subdivisions 

(eog. x and Y, see Figure 3-2) of W, instead 

of assigning a single Internet network 

number to network W. Thus, network W 

would become a complex of several Internet 

networks, and the structure of W 

would be visible even outside of it. 

because there are packets to "foreign" 

networks which need not be routed via a 

local gateway but can be sent directly: 

Consider packets to be sent from HX (former 

HW1) to HY (former HW2). Note that 

and HY are now hosts attached to different 

Internet networks, but direct connections 

can still be established between HX 

and HY without transiting an Internet 

gateway! According to the current routing 

algorithms, HX would determine that the - 

destination HY is on a different ("foreign") 

Internet network and would therefore 

decide that the packets must be sent 

to a local gateway on the common network 

x. There is only one gateway GAX connected 

to network X, but transmitting packets 

to GAX would be unreasonable, since they 

can be sent directly to HY. But HY is 

neither a gateway nor is it a host on the 

local net. Similarly gateway GAX would 

encounter the same problems in its routing 

decision as; HX when forwarding packets 

to HY. In addition gateway GAX cannot 

send an ICMP Redirect message to HX specifying 

HY as a better first hop on the 

route towards the destination, because 

HYis not a host: on the same network. 

Therefore, the following model of a clustering 

scheme is proposed, which adds an 

additional level to the interpretation of 

!nternet addresses and is called "Cluster 

Addressing Scheme": 

3.1o Cluster Addressing Scheme Model 

Specific Internet network numbers are assigned 

to a set of nets between which direct 

connections can be established without 

transiting a gateway. These networks 

are associated to an "Internet Cluster". 

For all routing decisions within the 

cluster~ and ~or the speci~ica~£on that 

different Internet networks are associated 

to a cluster, the use of an addressmask, 

called "Cluster-Mask", is proposed. 

By means of this cluster-mask, all hosts 

within the same cluster, even if attached 

to different Internet networks appear to 

be local. ICMP Redirect messages can be 

sent directly between gateways and hosts 

belonging to the same cluster. The fact 

that several Internet networks are aggregated 

to an Internet cluster is invisible 

to the outside world. However the internal 

structure of the cluster, which is a 

complex of Internet networks ("clusternets"), 

is visible outside the cluster. 

The 32-bit INT~RN~T address consists of: 

3-2 

However this assignment would be inconsistent 

.with the current routing model, 

::= 

 

Now the cluster addressing scheme proposes 

that the field is 

interpreted as 

-363-

: := 

 

Although this subdivision of the 

field is used for routing 

decisions within the cluster, it is invisible 

to the outside world° 

Thus, if this clustering scheme is in 

use, the INTERNET address can be interpreted 

as 

::= 

 

Consider the example of a (wide-area) 

network w as discussed above (Fig. 3-1). 

Assume that direct connections can be established 

(pairwise) between all hosts 

~nd gateways attached to network Wo Further 

assume that network W is inhomogeneous; 

’ for example the costs for a connection 

between GAWI (or HWI) and HW2 (or 

GBW2) are three times higher than between 

GAWI and HWl (or GBW2 and HW2)o Now, according 

to the cluster addressing scheme 

specific internet network numbers [wl] 

and [W2] are assigned to homogeneous subdivisions 

of W as shown in Figure 3.1-io 

These Internet networks Wl and W2 are associated 

to an Internet cluster (w-cluster). 

If packets are to be sent from HWl 

to HW2, host HWl can determine by means 

of a cluster-mask that HW2 is a "local" 

host since it belongs to the same cluster. 

Therefore, the packets can be routed 

directly ("locally") by establishing 

direct connection to h’W2. If for some 

reason the packets are sent to gateway 

GAWI, then~ according to the clustering 

scheme, GAWI can send an ICMP Redil:ect 

message to HWl specifying HW2 as a be~:ter 

first hod in this message. These routing 

mechanis~s are described in detail in the 

following sections. 

field are used to specify 

the cluster. In this cluster-mask all 

bits corresponding to the 

field are set to one, while the remaining 

bits are set to zero. If the 

width, of the field 

is zero (e.g., if the cluster-mask contains 

all ones in the 

field and zeros in the ) the 

net does not belong to any Internet 

cluster° 

For example, if a set of class B networks 

with Internet addresses whose 8 highorder 

bits are identical is associated 

with an Internet cluster, the clustermask 

would have the following value: 

< res~- field > 

< rest - field > 

llllllll000000000000000000000000 

binary 

255. 0. 0. 0 decimal 

cluster-mask 

By means of this cluster-mask a host can 

determine if it is connected to a cluster-net. 

The host uses this mask for the 

routing decision if the destination IPaddress 

specified in a datagram is either 

"local" or "foreign" depending whether 

the destination is in the same cluster or 

not. All datagrams to local destinations 

(even on different Internet networks 

(cluster-nets)) can be sent directly 

the destination without transiting an 

Internet gateway. 

If the bitwise AND of this clustermask 

with the destination IP address 

("dg.ip_dest") matches the bitwise AND 

the ~ask with. the host’s own IF address 

("my ip addr"), the destination is assume~ 

t~ be in the same cluster, and 

therefore the datagram can be sent directly 

("locally"); if not, the destination 

is assumed on a network outside the 

cluster, reachable only via a gateway. 

If an IP implementation supports subnets 

[7], (normally) no changes to the code 

are necessa~ Y ...... to support ’--" i- the mask" clustering must De 

scheme, except 5nmu ~_ ~_ ~ 

assigned the value of the ciuster-mas~: 

IF bitwise and(dg.ip dest,my ip mask) 

THEN send dg locally(dg,dg.ip dest) 

ELSE send’-dg-locally(dg,gatew~y to 

(bitwise’-an~(dg.ip dest,my io ~ask))) 

3.3. ICMP Address Mask Request - Reply 

3.2. Clust.~ 

A ho~t us~, a ~.’,-bit mask, called "clus- 

-t~r-m~k"’ %’~ ,~-termine which bits of the 

Todetermine which cluster-mask (address 

mask) is in use, the two ~CMP messages 

(specified in RFC-950 [7]) 

- ICMP Address Mask Request 

- ICMP Address Mask Reply 

¯ 

-364-

can be used without changes. ~ The address 

mask field of a Reply message contains 

the value of the 32-bit cluster-mask. 

3.4. ICMP Redirect Messages 

Due to the fact that all hosts and gateways 

within the same cluster appear to be 

reachable "locally", the cluster addressing 

scheme allows to send ICMP Redirect 

messages between gateways and hosts within 

the same CLUSTER and not only within 

a directly connected Internet NETWORK. 

This is a significant extension of the 

usage of the ICMP Redirect message. 

3.5° Advantages and Disadvantages 

The concept of associating a set of Internet 

networks to an Internet cluster 

and the specification of a cluster-mask 

has the following advantages: 

- The internal structure of a cluster, 

consisting of a set of !nternet networks, 

is visible to the outside world. 

This can be important for routing decisions 

outside the cluster. 

Re~ark: The disadvatage of reserving 

Internet network numbers for the clustering 

scheme seems to be acceptable 

due to the fact (see RFC-1020 [5]) that 

with regard to a maximum number of 

126 Class A networks, 27 (21.4%) 

16382 Class S networks, 301 (1.8%) 

2097150 Class C networks, 7494 (0.4%.) 

network numbers are assigned, and especially 

those network classes (B and C) 

with the higher percentage (98.2 % and 

99.6 %) of available numbers are those 

which are of more interest for the 

clustering scheme. 

4. APPLICATION OF THE CLUSTERING SCHEME 

TO X.25 PUBLIC DATA NETWORKS 

The international, system of X.25 Public 

Data Networks (PDN) is a typical widearea 

network (WAN). In this system, the 

national packet-switched data networks in 

various countries are connected via gateways 

(CCITT, Rec. X.75 [8]) to allow international 

interworking between hosts on 

different national public data networks 

over international virtual circuits. 

- The fact that an Internet cluster has 

been formed is invisible outside the 

cluster. Therefore, no changes to the 

existing Internet gateway system are 

necessary to support the cluster addressing 

scheme. 

- All hosts (gateways) within the same 

cluster appear to be reachable directly 

("locally"). This is important for 

rou~ing decisions within the cluster. 

- No changes, or minor ones only, to 

hosts supporting subnets 

- ICMP Address Mask Request and Address 

Mask ReDly messages can be exchanged to 

determine which cluster-mask is in use. 

- ICMP Redirect messages can be used between 

gateways and hosts on different 

Internet networks, but within the same 

.cluster. 

Disadvantages 

are: 

- Specific Internet network numbers must 

be reserved for each cluster. 

For the implementation of the clustering 

scheme and for the reservation of 

Internet network numbers for specific 

clusters, it is proposed to assign (reserve) 

a number (depending on the number 

of bits (width) of the 

field of the ) 

of the highest, not yet assigned 

network numbers of each class of 

networks. 

-365- 

4.1o Costs 

The costs for international virtual circuits 

differ from those for national virtual 

circuits and depend on: 

- The charge for the call request 

- The length of time the virtual circuit 

is open 

- The data volume transmitted over that 

circuit in units of "segments" 

Some ~acilities ("closed user ~roup", 

"reverse charging", etc.) are usually not 

available for international calls. 

4.2. X.121 Addressing 

An X.121 address (CCITT, Rec. X.121 [8]) 

is assigned to each PDN host. 

This international data number consists 

of: 

::= 

or 

::= 

whe re 

DNIC .... Data Network-Identification 

(fixed at 4 digits) 

NTN .....Network Terminal Number 

(up to l0 digits) 

Code 

DCC ..... Data Country Code (fixed at 

digits, first 3 digits of DNIC) 

NN ...... National Number (up to iI digits)

DNIC . z denotes any digit from 2 thru 7 

zxxn (8..te!ex, 9..telephon) 

DCC x denotes any digit from 0 thru 9 

n denotes any digit from 0 thru 9 

(network digit) 

Thus, the system of data network identification 

codes (DNICs) as specified 

Rec. X.121 [8] provides a theoretical 

maximum of 6000 (resp. 8000) DNICs. However, 

only about 100 national public data 

networks are in operation so far. 

Currently an Internet class A network 

number [!4.rrr.rrr.rrr] is assigned to 

the system of public data networks (PDN). 

For the time being the assignment of 

Internet addresses to hosts (gateways) 

PDN is done successively in (chronological) 

order of request, regardless to 

which national public data network a host 

(gateway) belongs° 

Connectivity with the Internet is provided 

by so called "VAN gateways", which 

are attached to the national public data 

networks° 

4o3. Characteristics 

The PDN can be characterized 

as follows: 

- wide-area network 

- Complex of national public data networks 

- Internat. virtual circuits are provided 

- Different costs for international and 

national virtual circuits 

- Costs depend on length of time and data 

volume transfered 

- No broadcasting and no multicasting 

4.4. Routing Thru PDN - Current Situat.ion 

Due to the characterization above, the 

following requirements seem to be reasonable 

for the routing of !nternet datagrams 

through PDN: 

- Routing decisions should be done with 

regard to the structure of the PDN 

(complex of national public data net-- 

works) 

- Packets between PDN hosts should be 

sent directly through the PDN over virtual 

circuits 

The current routing situation in the 

DARPA Internet with regard to PDN is 

very poor: 

Due to the assignment of a class A network 

number to the system of public data 

networks (PDN), no internal structure 

this PDN system is visible to the outside 

world. For this reason a division of the 

?DN into subnets would have no external 

effects. 

Currently, the PDN is declared reachable 

via the ,,BBN-~N-GATEWAY". However, since 

the ~’BBN-VAN-GATEWAY" does not provide 

international calls, PDN hosts on other 

national public data networks are unreachable 

from the Internet through PDN. 

(NOTE: A connection from (!) a PDN host 

to any Internet host via the "BBN-VAN- 

GATEWAY" is possible). 

Packets sent from a PDN host via a VAN 

gateway on the same national public data 

network to any !nternet host will reach 

the destination° However, due to the current 

routing in the Internet, which is 

,,network_centric ~’ not "gateway-centric", 

reply packets will be routed to the 

"BBN-VAN-GATEWAY"- Assuming that an international 

virtual circuit between the 

,,BBN_~VAN_GATEWAY" and the PDN host does 

not exist, these reply packets will not 

reach the PDN host, since the "BBN- 

VAN-GATEWAY" does not make international 

calls° Therefore, connections from PDN 

hosts via VAN gateways other than the 

"BBN--VAN-GATE%~Y" cannot be established. 

4.5° PDN-Cluster Addressing Scheme 

To allow an improved routing of Internet 

datagrams thorough ~DN according to the 

Internet routing model, we propose to 

apply the "Cluster Addressing Scheme" 

(presented in Section 3 of this paper) 

the system of X.25 public data networks: 

a) Internet class B network numbers (with 

identical bits in the first (highorder) 

8-bit field of the Internet address) 

are assigned to national public 

data networks° 

b) The ~ national public data networks are 

associated, to an Internet cluster 

("?DN-Cluster") 

c) For the specification of this cluster 

and for routing decisions within the 

d) 

~:luster, a cluster-mask is used (value 

)~ thus all hosts within 

the PDN-C].uster appear to be reachable 

"locally"~ 

ICMP Redirect Messages can be sen~ to 

any PDN host to manage the routing 

within the FDN-cluster. 

NOTE: No changes to the existing Internet 

gateway syst,~m are necessary to support 

the cluster addressing scheme other than 

reserving a set of class B network numbers 

for the PDN-cluster and implementing 

this scheme on VAN-gateways and PDNhosts. 

On hosts supporting subnets [7] 

this can be done very easily by simply 

setting the address-mask to the value of 

the cluster-mask. Following is a detailed 

description of the PDN-cluster 

addressing scheme. 

-366-

4.6. PDN-C!uster 

Due to reasons of homogenity (cost structure, 

available network options, etc.) 

mapping between Internet network numbers 

and Data Network Identification Codes 

(DNICs, Recomm. X.121 [8]) is proposed. 

Therefore Internet class B network numbers 

with identical bits in the first 

(high-order) 8-bit field of the Internet 

address (see below) are assigned to the 

different national public’ data networks. 

This allows a maximum number of 65.536 

PDN hosts on each network° 

The national public data networks are associated 

to an Internet cluster (PDNcluster). 

For this reason the 16-bit 

field (class B network) is divided 

into an n-bit field and 

a (16 minus n)-bit 

field: 

::= 

 

(n bits) + (16-n bits) 

In deciding how many bits of the 

field should be used for the 

field it seems to be 

reasonable to distinguish between: 

- Theoretical number of addressable DNICs 

(see Recomm. X.121 [8]) 

- Number of reachable DNICs currently 

(and in the near future) 

The system of Data Network Identification 

Codes (DNICs) as specified in Rec. X.121 

[8] provides a theoretical maximum of 

6000 (resp. 8000) DN!CS. 

However, only about 100 different national 

public data networks are reachable 

currently. 

¯ 

Even assuming an increase of additional 

public data networks, a maximum number of 

256 (254) addressable DNICs seems to 

sufficient for the near future 

Therefore, it is proposed to use an 8-bit 

-field for the PDN-cluster 

and an 8-bit field: 

::= 

 

(8 bits) (8 bits) 

This allows to address 256 (254) different 

national public data networks with 

65.536 FDN hosts on each. 

According to the cluster addressing 

scheme, the reservation of Internet network 

numbers for an Internet cluster 

should start with the highest, not yet 

assigned network numbers of each class. 

Therefore, the assignment of the clusternumber 

[191.nnn.rrr.rrr] to the PDN-cluster 

is proposed, thus to reserve 6he Internet 

network-numbers [191.001.rrr.rrr] 

up to [191.254.rrr.rrr] for the different 

national public data networks. 

The assignment of !nternet network numbers 

to the national public data networks 

(different DNIC’s) could be done in the 

order of request (by grouping requests 

for zones 2 to 7). 

The following Internet network numbers 

could be assigned so far: 

DNIC Public Data Network INTE~NET ~ 

2041 DATANET (Netherlands) 

2342 IPSS (U.K.) 

2405 TELEPAK (Sweden) 

2624 DATEX-P (West Germany) 

~llO 

~ELENET (US~) 

19!.001 

19!.002 

191.003 

19!.004 

191.09~ 

reserved 19!. 255 

4.7. PDN-Cluster-Mask 

For the specification of the PDN-cluster 

and for internal routing decisions within 

the cluster 

3.2 above), 

(as described in detail in 

corresponding to the width of 

the field, a clustermask 

is used in which the first (highorder) 

8 bits are set to "one", while the 

remaining bits are set to "zero" (value 

). 



llllllll000000000000000000000000 

binary 

255. 0. 0. 0 decimal 

cluster-mask 

If the bitwise AND of this clustermask 

with the destination IP address 

("dg.ip_dest") matches the bitwise AND 

the mask with the host’s own IP address 

("my ip addr"), the destination is assume~ 

t~ be in the same cluster and 

therefore the datagram can be sent directly 

("locally"); if not, the destination 

is assumed on a network outside the 

cluster, reachable only via a gateway. 

IF bitwise and(dg.ip dest,my ip mask) 

bi twise-and( my ip-addr, my-ip-mask 

THEN send dg-locall~(d~,dg.ip ~es~) 

ELSE send-dg~locally(dg,gatew~y_to 

(bitw[se_and(dg.ip_dest,my_zp_mask))) 

If an IP implementation supports suhnets, 

(normally) no changes to the code are

necessary to specify the FDN-cluster, 

except that "my~ip mask" must be assigned 

the value o~ ~he "PDN-cluster-mask" 

. 

Thus all PDN hosts within the PDN-cluster 

appear to be reachable "locally". In 

fact, direct national and international 

virtual circuits can be established between 

PDN hosts. 

4.8. ICMP Address Mask Request - Reply 

To determine which cluster-mask (address 

mask) is in use, the two ICMP messages 

(specified in RFC-950 [7]): 

- ICMP Address Mask Request (AM!) 

- ICMP Address Mask Reply (AM2) 

can be used without changes. The address 

mask field of a reply message contains 

the value of the PDN-cluster mask. 

4.9. ICMP Redirect Messages 

Due to the concept of the cluster addressing 

scheme all hosts and gateways 

within the same cluster (even on different 

Interne~ networks) appear to be 

reachable "locally". Therefore, to manage 

the routing within the PDN-cluster between 

PDN hosts and VAN gateways, ICMP 

Redirect messages can be sent to any host 

in the PDN-cluster, specifying any PDNgateway/host 

as a better first-hop towards 

the destination in the redirect 

message. 

4o10. IP Source Route Option Included by 

VI~N-Gateways 

While the PDN is based on connection 

oriented protocols, the Internet uses a 

a datagram oriented packet-switching 

technology. Therefore it miqht happen 

that packets between two !nternet hosts 

are not routed along the same path° 

Let us assume that 

gateways vl and v2 

there are two VAN 

and a PDN host HP1, 

which are attached to a national public 

data network P1 as shown in Figure 

4.10-i. To send packets to a host HA 

on network A~ HP1 establishes a switched 

virtual circuit to Vl. The packets forwarded 

by V1, are received at host HA; 

however, reply packets from HA to H~]o are 

routed (for some reason) to V2. Now~ 

would have to open a virtual circuit 

HP1 to forward the packets to the destination 

HP!. 

Figure ~,. I0-I 

In most applications it seems to be reasonable 

to avoid such a situation for the 

following constraints: 

- Technical: HPI might 

with 1 logical 

be configurated 

channel only: 

Thus, an incoming call from V2 

cannot be accepted, if the virtual 

circuit to vl should remain 

established. 

- Costs: Two virtual circuits would be in 

use. Vl and V2 might accept incoming 

calls only, but do not 

open a connection to HPI since 

the calling site has to pay for 

the connection. (No reverse 

charging on international calls) 

Since many Internet hosts use the IP 

source route ,option, when it is. specified 

in received packets, even in their reply 

packets - a policy which is recommanded 

to be implemented on each host - a new 

use of the IP source route option is proposed 

to avoid the situation described 

above: 

VAN gateways include their own Internet 

address (corresponding to the directly 

connected networ~ interface through which 

a packet is transmitted) as an IP source 

route option in those datagrams, which 

are received from the ,,PDN-cluster-net" 

interface and forwarded to another network 

interfaoe, by extending the Internet 

header by 8 (resp. 4) octets according 

the following algorithm: o. 

- 

If no source route option is specifie~ 

in the original datagram, the Internet 

header is extended by 8 octets and the 

VAN gateway address is included as a 

Loose Source Route (LSR) option: 

-368-

- If a Loose Source Route (LSR) or 

Strict Source Route (SSR) option is already 

specified and the source route 

list does not contain the VAN gateways 

address, the source route list is extended 

by the VAN gateways address (4 

octets, inserted as indicated by the 

pointer); the option length and the 

pointer are incremented by 4: 

NOTE: Other options in the Internet header 

are uneffected; the source address and 

the destination address are left unchanged; 

if necessary, the Internet header 

is padded to a 32 bit boundary; the 

Internet Header Length (IHL), the Total 

Length and the Header Checksum are recomputed. 

Thus, packets from HPI via Vl to HA (see 

example above) are routed back (along the 

same path) from HA via V1 to HPI, if Vl 

includes its own internet address as an 

IP source route option in packets from 

HPI to HA, and HA uses this option in its 

reply packets to HP!o 

5o 

SUMMARY 

In this paper, a new concept of a cluster 

addressing scheme, in which a set of 

Internet networks is aggregated to an 

Internet cluster has been presented. Its 

application is of interest especially for 

WANs, since the structure of the WAN becomes 

visible even outside of it (important 

for Internet rout±n~), while the 

fact that a cluster has been formed is 

invisible outside the cluster. Therefore 

no changes to the existing Internet gateway 

system are necessary. 

For routing decisions the use ~f a cluster-mask 

is proposed; therefore all hosts 

within the cluster (even hosts on different 

Internet networks) appear to be 

reachable locally. If "my ip mask" is assigned 

the value of the crusher-mask, no 

changes, or minor ones, are necessary to 

support the cluster addressing scheme in 

hosts whose software allows the implementation 

of subnets. Even the two ICMP messages 

"Address Mask Request" and "Address 

Mask Reply" can be used without changes 

to determine which cluster-mask is in 

use° As a significant extension, !CMP Redirect 

messages can be used not only between 

gateways and hosts on the same 

Internet network, but also within the 

same cluster. 

In addition, the application of the proposed 

cluster addressing scheme to the 

system of X.25 Public Data Networks (PDN 

has been discussed. The PDN is a typical 

wide-area network, which consists of a 

number of national public data networks. 

Currently, due to the fact that only one 

Internet class A address is assigned to 

the PDN, it appears to be unstructured 

and therefore the routing of Internet 

datagrams through the PDN is very poor. 

To provide an improved routing the application 

of the cluster addressing scheme 

is proposed by assigning Internet class B 

network numbers to the national public 

data networks and associating these networks 

to the PDN-cluster. The proposal 

involves no changes to the existing 

’ !nternet gateway system other than a 

policy reserving a set of class B network 

numbers for the PDN-cluster and implementing 

the cluster addressing scheme on 

VAN gateways and PDN hosts. For routing 

decisions within the cluster, the use of 

a cluster-mask has been discussed. PDN 

hosts whose software supports subnets can 

be equipped easily with the cluster addressing 

scheme. Finally, with regard to 

the connection-oriented characteristics 

of the PDN, a new use of the IP source 

route option (included by VAN gateways) 

has been discussed. The implementation of 

the proposed cluster addressing scheme 

would allow worldwide interoperation beween 

the many local area networks in 

various countries now using DARPA-Internet 

TCP/!P protocols. 

ACKNOWLEDGMENT 

It has been the poor routing of Internet 

datagrams through PDN, especially from 

the European point of view, which caused 

the ~evelopment of the cluster addressing 

scheme and its application to FDN as described 

here. J. Noel Chiappa, Horst D. 

Clausen, J.J. Garcia-Luna, Dave Mills and 

Jon Postel provided helpful discussions 

and important suggestions. 

REFERENCES 

[!] Postel, J., ed., "!nternet Protocol - 

DARPA In~ernet Program Protocol Specification", 

DARPA Network Working 

Group Request For Comments RFC-791, 

USC/Information Sciences Institute, 

Sept. 1981. 

[2] Postel, Jo, ed., "Internet Control 

Message ~rotocol - DAR~A Internet 

Program Protocol Specification", 

RFC-792, USC/Information Sciences 

Institute, Sept. 1981. 

[3] Hinden, R., Sheltzer, A., "The DARPA 

Internet Gateway", RFC-823, Bolt, 

Beranek and Newman Inc., Sept. 198Z. 

-369-

[4] 

Mills, D.L., "Exterior Gateway Protocol 

Formal Specification", RFC-904, 

M/A-COM Linkabit, Apr. 1984. 

[5] Romano, S., Stahl, M., "Internet Numbers", 

RFC-1020, Stanford 

Resea~:ch 

International, Nov. 1987. 

[6] GADS, "Toward an Internet 

Standard 

Scheme for Subnetting", RFC-940, 

DARPA Internet Gateway Algorithms and 

Data Structures Task Force, Apr. 1985 

[7] 

Mogul, J., Postel, J., "Internet 

Standard Subnetting Procedure", RFC- 

950, Stanford University and USC/!nformation 

Sciences Inst.~ Aug. 1985. 

[8] CCITT, Data Communication Networks. 

Transmission, Signalling and Switching, 

Network Aspects, Maintainance, 

Administrative Arrangements, Recommendations 

X.40 - X.180, Yellow Book, 

Volo VIII - Fascicle VIII.3, Geneva, 

1981 

Carl-H. Rokitansky is 

with the Fern University 

of Hagen where he is 

engaged in research on 

computer networks and 

their protocols. He is 

particularly interested 

in the design, modeling 

and analysis of routing 

algorithms for large 

mobile networks, and in 

developing gateway algorithms 

for the interconnection of computer 

networks° Until recently he joined 

the Telecommunications Institute of the 

German Aerospace Research Establishment 

(DFVLR). He received his JD from the 

University of[ Salzburg and his MS degree 

in economics (special field mathematical 

statistics and computer science) from the 

University of Vienna. In 1986/1987 

Dr. Rokitansky was a faculty member in 

the Electr±cal and Computer Engineering 

department of the University of Kansas in 

Lawrence. He is a member of the Internet 

Engineering Task Force and is chairing 

the Public Data Network Routing working 

group of the IETF. 

-370-

-371-

i I ! ! 

.,.4 

~ .~. 

-372--

-373-

-374-

II’I 

I 

000~0 

-375-

--376-

-377-

-.378-

-379-

’O0 

0 

© 

< -r 

-381-

-382-

-’384-

-386-

~ 0 

4-I 

-387-

-388-

-389-

-390-

-391-

-392-

-393-

-394-

-397-

398-

United States Department of Commerce 

National Institute ol: Standards and Technology 

Certificate of Accreditation 

LABORATORY, 

INC 

is recognized under the National Voluntary Laboratory Accredilation Program 

for satisfactory compliance with criteria e~tablished in Title 15, Part 7 Code of Federal Regulatio.s. 

Accreditation is awarded [or specific ser~ice~, listed on the Scope of Accredilation. [or:. 

COMPUTER NETWORK INTERFACE PROTOCOLS 

January, I, 19-- 

until 

-399~

’,- 

,_O& 

o0~ ~ I 

< 

r~ 

© 

0 ~ 

© 

o 

uJ o 

> -r"

o 

-403- 

¯ .

0~ o 

~4 o 

o o 

. 

o 

o 

~ ¯ 

-404-.

0 0 0 0

0 0 0

Proceedings (PDF) - Internet Engineering Task Force

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?