home *** CD-ROM | disk | FTP | other *** search
-
- Transport Area
-
- Director:
-
-
- o Allison Mankin: mankin@cmf.nrl.navy.mil
-
-
- Area Summary Reported by Allison Mankin/NRL
-
- The Transport Area Directorate is comprised of the following members:
- Dave Borman, Sally Floyd, Jim Hughes, Matt Mathis, Greg Minshall, Eve
- Schooler, and John Wroclawski.
-
- The Transport Services Area deals with protocols and algorithms that
- provide end-to-end transmission services in the Internet. We maintain
- the notion of transport services, not just transport protocols, because
- of the increasing variety of end-to-end requirements that the Internet
- is meeting, or will be expected to meet, in the near future.
-
- In the month after the Seattle IETF, two working groups were added to
- Transport Services because of the closing down of the Service
- Applications Area: ONCRPC and THINOSI. They are covered in the SAP
- report for Seattle, but they fit well into the Transport Area Director
- and Directorate's sense of the scope of the Transport Services Area.
-
- Since the last report, we have increased the directorate, reflecting
- both the increase in the number of our active working groups and the
- area director's temporary assignment to co-direct the IP: Next
- Generation Area (with Scott Bradner). The directorate is primarily
- responsible for quality review of the working groups. They also
- contribute to our planning with their diverse and far-sighted
- perspectives on the Internet.
-
- Among the future issues for TSV that we are thinking on are: improving
- distributed file systems, fully documenting as standards TCP's adaptive
- algorithms (for the moment, Sally Floyd reports that the account in
- Richard Steven's TCP/IP Illustrated 2nd Edition will be correct and
- complete), completing selective acknowledgment in TCPLW, and developing
- an informational activity on the integrated layer processing technique,
- which is strongly related to transport services implementation issues.
-
- The Transport Services Area working groups that met in Seattle offer
- their brief summaries below. INT-SERV met as a BOF in Seattle, but it
- has since become a working group. ONCRPC is included in the SAP report
- for Seattle.
-
-
- Audio/Video Transport Working Group (AVT)
-
- The meeting began with a brief report on the status of the Real-time
- Transport Protocol (RTP). The draft RTP specification was submitted with
- a request for Last Call just before the previous IETF meeting in
- November. The review by the Transport Area Directorate called for
- several changes so that RTP would more closely follow the principles of
- application level framing. In two discussions between Steve Casner, Ron
- Frederick and Van Jacobson in which the vat and nv programs were taken
- as design examples, the following list of proposed changes was
- constructed:
-
-
- o Carry the control and data traffic on separate ports
-
- o Move the application-level multiplexing of the channel ID to an
- encapsulation, for the cases where it is needed
-
- o Minimize the use of options
-
- o Make the definition of some fields application-specific (in
- particular, the timestamp clock rate and sync marker)
-
- o Use global rather than local IDs, to be able to detect loops
-
- o Specify more precisely how reception reports should be provided
-
-
- The first 90 minutes of the first session, and the beginning of the
- second session were occupied by a presentation of these changes. The
- attendees generally agreed with the changes, and in particular agreed
- that the global identifiers would always be 32-bit random numbers rather
- than allowing the IPv4 address to be used as an identifier; as a
- consequence, the identifier of the synchronization source will always be
- included in a new field added to the fixed RTP header. There are
- several details remaining to be defined, in particular the mechanisms
- for padding the message to a multiple of the encryption block size, and
- for carrying the authentication information, and the exact structure of
- the control packet.
-
- Our task now is to complete the design to address these details, update
- the specification and get consensus from the working group via e-mail.
- Steve Casner will take responsibility for sending out a more complete
- draft of the proposed changes to start the discussion. The goal is to
- submit the draft for Last Call after review at the July IETF meeting in
- Toronto.
-
-
- Integrated Services Working Group (INTSERV)
-
- The first meeting was an organizational meeting, describing the
- motivations for the group, its organization, and timeline. The goal of
- INTSERV is to make the Internet friendly to real-time applications
- (e.g., multimedia conferencing) by enhancing the Internet architecture
- to support integrated services.
-
- The proposed working group organization calls for Craig Partridge to be
- the working group chair, and John Wroclawski, Scott Shenker and Dave
- Clark to be co-chairs. It was explained that the large management team
- is intended to ensure that the necessary outreach to various affected
- communities is made.
-
- The working group timeline calls for delivery of several RFCs over the
- next two years.
-
- The second session was devoted to trying to investigate what
- requirements integrated services might place upon IPng. Craig explained
- that this was definitely putting the cart before the horse, given that
- the group had barely had a chance to talk about proposed integrated
- services architectures, but at the request of the IPng Directorate, a
- discussion was held.
-
- At the end of the meeting, the proto-working group concluded that there
- were two requirements it would like to place on IPng:
-
-
- o That an IPng have some mechanism to locate per-datagram
- classification information (e.g., flow state) and that the
- mechanism should be consistent with forwarding at the media speeds
- expected in the future.
-
- o That an IPng should have mechanisms to hinder Bob from using or
- disrupting resources that Alice has been granted and is using.
-
-
- Craig Partridge was tasked to write up these points and circulate a
- draft to the working group, for consideration as submission as a white
- paper to the IPng directorate.
-
-
-
- Multiparty Multimedia Session Control Working Group (MMUSIC)
-
-
- During the Seattle meetings of the MMUSIC Working Group, there appeared
- to be a convergence of ideas about the general framework and protocols
- required for session control in the Internet, and a readiness to take
- steps toward interoperability of existing applications. The group
- identified at least two services that system builders might need and
- use; CCCP, a bus-based protocol that could provide an API-level
- messaging abstraction, and the agreement algorithm on which a session
- service could be built. In addition, there was interest in trying to
- understand, in the present context of the Internet/MBone/WWW, what
- constitutes a session and what are the functions that can be performed
- on sessions once they exist. Thus, a variety of session rendez-vous
- mechanisms were described. A final discussion focused on the relevance
- of reliable multicast to a membership management protocol. From formal
- and informal conversations with working group participants, it was clear
- that these ideas are ready to be codified and written down.
-
-
-
- Resource Reservation Setup Protocol Working Group (RSVP)
-
- The RSVP Working Group met twice during the Seattle IETF. The first
- session was devoted to an overview of the protocol and a report on the
- status of an initial implementation. Several issues were raised and
- discussed. The second session was largely devoted to further discussion
- of a number of basic issues.
-
- The working group plans to hold an MBone conference before the next IETF
- meeting (the MBone meeting has been scheduled for 23 June), and to
- conduct further discussion by e-mail. There were several action items
- to prepare position papers on particular issues. The draft
- specification will be updated with some additions suggested at the
- meeting.
-
- Many of the hard issues under discussion concerned functional
- modularity, especially between resource reservation and routing.
-
-