One document matched: draft-wenger-clue-transport-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wenger-clue-transport-01" ipr="trust200902">
  <front>
    <title abbrev="clue-transport">Transport Options for Clue</title>

    <author fullname="Dr. Stephan Wenger" initials="S." surname="Wenger">
      <organization>Vidyo</organization>

      <address>
        <postal>
          <street>433 Hackensack Ave</street>

          <city>Hackensack</city>

          <region>NJ</region>

          <code>07601</code>

          <country>USA</country>
        </postal>

        <email>stewe@stewe.org</email>

      </address>
    </author>

    <author fullname="Marshall Eubanks" initials="M." surname="Eubanks">
      <organization>AmericaFree.TV</organization>

      <address>
        <postal>
          <street>P.O. Box 141</street>

          <city>Clifton</city>

          <region>Virginia</region>

          <code>20124</code>

          <country>USA</country>
        </postal>

        <phone>+1-703-501-4376</phone>

        <email>marshall.eubanks@gmail.com</email>

       </address>
    </author>
    <author fullname="Roni Even" initials="R." surname="Even">
      <organization>Huawei</organization>
    <address>
          <email>ron.even.tlv@gmail.com</email>
    </address>
    </author>

    <author fullname="Gonzalo Camarillo" initials="G." surname="Camarillo">
      <organization>Ericsson</organization>
        <address>
          <email>Gonzalo.Camarillo@ericsson.com</email>
        </address>
    </author>

    
    <date day="24" month="October" year="2011" />

    <abstract>
      <t>This memo describes the assumption and the proposed options for the coding and transport of CLUE messages as outlined in version 01 of the framework draft.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="Intro" title="Introduction">
      <t>The CLUE WG is chartered to design a protocol working in conjunction with the IETFÕs protocol suites of choiceÑnamely SIP for basic call setup and control and RTP for media transport.  This document describes options for the coding and transport of CLUE messages in a SIP / RTP environment.  Specifically, three issues are addressed.</t>

<t>First, while the framework draft conceptually describes message flows, it does not specify how those messages are actually transferred Òon the wireÓ and how they relate to the SIP offer/answer [rfc3264].  This document lists the options that have been proposed  in CLUE to date, plus some new ones derived by the authors.</t>

<t>Second, the framework-01 draft describes three messages between the producer and the consumer in an abstract form, without specifying the details of the representation of those messages.  This memo lists (some of) the options for the ÒcodingÓ of the abstract messages of the framework draft.</t>

<t>Third, before any CLUE messages can be meaningfully exchanged, it is necessary to discover whether the involved systems are actually CLUE-capable.</t>

<t>In version -00 of this document we deliberately list all options we could come up with, however likely they may be to find consensus in the group.  Deciding on the appropriate mechanism (or mechanismsÑ it is not always appropriate to have a single solution for a given problem, though this is of course desirable from an interoperability viewpoint) is left as an exercise for later.  That does not mean that the authors do not have preferences, and/or specific knowledge of certain mechanisms, and would go in greater depth in describing one mechanism while being superficial in describing another.</t>

<t>The message ladder diagram will be added once we decide on the transport of the CLUE messages
</t>
</section>



      <section anchor="assumpt" title="Assumptions">
        <t>The Basic Clue data model is specified in the framework document.  The framework defines three messages that carry the Clue data:</t>

        <t>Provider Capabilities Announcement</t>
        <t>Consumer Capability Message</t>
        <t>Consumer Configure Request</t>

<t>CLUE messages may need to be sent at the initialization of a call, and possibly in irregular intervals which are spaced apart in the order of seconds, minutes or even longer.</t>
<t>There is no hard real-time transmission requirement for CLUE messages; latencies in the seconds range are acceptable.</t>
<t>The Clue message handshake is different from the offer/answer exchange [rfc3264], primarily because the CLUE exchange is uni-directional, requiring  a similar exchange for each side of the media flow, while one offer/answer exchange  defines both sides of the media flow. </t>

<t>There is no hard requirement for synchronization of CLUE messages, though there may be a need for sequencing, (TBD).</t>

<t>CLUE messages may need to describe the characteristics of all endpoints in a conference (TBD), and that conference can potentially include dozens of endpoints.</t>

<t>There will be an SDP offer/answer exchange as part of the solution. The offer/answer will be used to establish the media channels and negotiate SDP parameters as well as to allow interoperability with systems that do not support the CLUE protocol.  The CLUE data will try to not duplicate SDP attributes.</t>

      </section>

      <section anchor="trans" title="Transport for CLUE messages">
        <t>CLUE messages need to be conveyed from one CLUE capable system to another.  This conveyance is called ÒtransportÓ of CLUE messages.  It should be clear that the message transport can be based on a transport layer (layer 4 in ISO/OSI) protocol or other layers, such as the application layer.</t>
        <t>In contrast to the Òcontent representationÓ, the transport of CLUE messages is somewhat more tightly bound to the environment.  In some scenarios it may be possible to reuse most of the mechanisms defined in an option for transport between SIP and H.323, while in others this is not possible.</t>

<t>The selection of the transport may have some affect on the content representation.(Need to write more about the specifications that need to be written, ie. SIP-INFO package, RTP payload format, etc.)</t>

<section anchor="t1" title="Option 1 : Piggy-pack on SIP">

<t>SIP includes a number of methods that can carry (directly or through content indirection) CLUE messages.  Many of these messages can be exchanged during the lifetime of a session without having adverse side effects such as complete codec initialization (what happens today in many products when using re-invite).  Piggy-packing CLUE messages on SIP has the advantage that any built-in transport and reliability mechanisms of SIP can be re-used.  It also has the feature (advantage?) that CLUE signaling is being conveyed in the signaling plane rather than in the media plane (making things such as decomposition potentially easier and certainly more intuitive). </t>

<t>One option that was mentioned before was to define a new INFO package [RFC 6086].
When looking at using SIP signaling there are other options like subscribe/ notify or Message method, see RFC 6086 section 8.4.1.  Note that subscribe creates a separate dialog usage and is normally sent outside of existing dialog.
We can also use the UPDATE method [RFC3311]. There were concerns about using re-invite claiming that it takes too long since that commonly used codec boxes teardown every existing media session during re-invites.
RFC 3311 says that although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead.  This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval.  Such approval will frequently be  needed, and is possible with a re-INVITE.
The thinking so far was that if we want to encode the CLUE data not as SDP we may be better to use INFO.</t>

        </section>
        
        <section anchor="t2" title="Option 2: CLUE control channel on the media plane over UDP">
        
<t>During the initial SIP handshake, a CLUE channel is established (if both systems are CLUE capable).  Over this channel, secure UDP packets are exchanged in a reliable fashion, for example, by a CLUE defined protocol that can have a reliable handshake based on similar mechanisms in BFCP over UDP.  Standard ICE can be used to deal with firewalls and NATs.  Issues here are congestion control and the architectural issue that signaling information is conveyed in the media plane (which may or may not be anything beyond an aesthetic problem).</t>

        </section>
        
        <section anchor="t3" title="Option 3: CLUE control channel on the media plane over TCP">

<t>This option is similar to the use of CLUE on the media plane, but uses TCP as the transport protocol.  TCP takes care of reliability issues as well as congestion control.  However, the NAT/firewall traversal may be a major issue, as ICE-TCP has not seen any deployment in the video conferencing industry. In addition, keep-alive messages may present a problem for sessions with thousands of attendees, which is possible under some deployment scenarios. </t>

       </section>
        
        <section anchor="t4" title="Option 4: CLUE control channel over UDP and RTP">

<t>This option is similar to option 2, except that the mechanisms of RTP can be used to make the transmission sufficiently reliable (through re-transmission or FEC extensions of RTP).</t>  

       </section>
        
        <section anchor="t5" title="Option 5: FTP">

<t>CLUE messages could conceivably be placed into files, which could be polled at regular intervals (or through a simple message) using ftp.  A bit archaic and has security and NAT/filewall issues.  We mention this option for completemess only, and because it was used in at least one legacy telepresence system.  In the authorsÕ opinions, itÕs probably not a viable choice.</t>

       </section>
        
        <section anchor="t6" title="Option 6: HTTP">


<t> The authors have not studied this option, and suggest to remove it in the -01 option of this document unless people find it viable (and come up with text). HTTP transport over port 80 is increasingly used to get through NAT/firewall blockages, and this mechanism may be required if technologies such as RTCWEB begin to be used in videoconferencing and telepresence. Questions include, dach box has a web server?  Would there need to be a central web server for CLUE control at service provider? </t> 

       </section>
        
      </section>

      <section anchor="cr" title="Content Representation">
      
<t>The data model in the framework-01 draft does not have a specific representation of the data.  Many different representation ÒlanguagesÓ, for example XML, possibly SDP, ASN.1, and others can be used, and we need to decide on one.  The decision may be based on the selected transport, but not necessarily.</t> 

<t>One key observation that has to be made at this point (described in greater detail above) is that the framework-01 draftÕs message exchange system appears to make it impossible to directly add the CLUE exchange to the offer/answer mechanism SIP videoconferencing endpoints use today.  It is, therefore, not a hard requirement to use SDP for the representation of the CLUE messages.  We have a freedom of choice here, which is why this section exists.</t> 

<t>Another observation is that the IETF is not the only body who standardizes telepresence systems; the ITU-T is also working in this field. While it probably shouldnÕt be a hard requirement for an IETF document to allow for seamless interoperability with the H.323 standards suite, it appears to be desirable if it can be easily done.</t> 

<t>It is very well possible that even moderately complex CLUE messages may exceed MTU sizes commonly found in todayÕs Internet.  There has been discussion in CLUE of sessions with thousands of participants. Even if a CLUE message can be compressed into a few bytes for each endpoint, such sessions can easily violate the commonly found Ethernet 1492-byte MTU Accordingly, message transport protocols will have to be prepared to split CLUE messages into fragments, which has implications on the design complexity of those protocols. This problem is especially an issue for verbose representations, such as XML. </t> 

<section anchor="cr1" title="Option 1 : SDP">
<t>SDP and its various extensions are used in SIP based systems for the offer/answer exchange, and, therefore, those systems include SDP parsers that could probably be extended to support CLUE messages.  SDP is also a fairly compact, but still (though barely) human readable content representation language.  Against SDP speaks mostly that SDP was never designed to describe anything as complex as the CLUE data.  </t> 
       
        </section>

            <section anchor="cr2" title="Option 2 : XML">
<t> XML is very flexible, and the representation of choice for many IETF technologies not bound to a certain legacy.  It certainly allows for all flexibility needed to represent all CLUE messages currently considered.  It also is naturally extensible in a way SDP is not.  On the downside, XML is fairly verbose, which has implications on the transport.</t>
        </section>

            <section anchor="cr3" title="Option 3 : ASN.1">
<t>ASN.1 is similarly flexible and extensible as XML, and (in its binary representation) fairly compact.  While it is commonly used in H.323, and while the video conferencing industry certainly has access to the tools necessary to deploy ASN.1 (a major obstacle in other industries), it is not widely used by SIP implementations.</t>
        </section>
        
        <section anchor="cr4" title="Option 4 : Clue Defined Format">
<t>It is, of course, possible that the CLUE WG defines its own format, possibly compact, possibly binary and possibly extensible representation language or format for CLUE messages.  </t>
        </section>           
        
         <section anchor="crex" title="Examples">
    <t>An example or examples should be added here when possible</t>
        </section>
             
      </section>

    <section anchor="cd" title="Clue Discovery">
    
<t>This section summarizes ways to discover whether systems involved are CLUE-capable.  For simplicity, point-to-point scenarios are assumed.  Multipoint scenarios can potentially make discovery considerably more complex.</t>

<t>Discovery appears to be necessarily bound to the capability exchange of the involved systems.</t>

        <section anchor="cd1" title="Option 1 : CLUE discovery as a side effect of opening a CLUE control channel">
<t>If, for the transport of CLUE messages, a media plane control channel were used (option 2,3,4 of the transport options), then the discovery of CLUE capability would be a side effect of the opening of this control channel during the initial offer/answer exchange.  </t>
        </section>  

        <section anchor="cd2" title="Option 2 : SIP Message Transport">
<t>If we use the INFO message then by using  the Recv-Info header field the support for the CLUE package can be signalled. </t>
        </section>  

   </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Any method for bypassing NAT/Firewall protections of course brings security issues, which need to be dealt with. </t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The list of authors needs to grow.</t>
    </section>
  </middle>

  <back>
     <references title='Informative References'>

      <?rfc include='reference.RFC.2119'?>
       "> 
    </references>
  </back>
</rfc>