Subject: [P2PSIP] ICE payload layout suggestions for draft-ietf-p2psip-base

From: "Craig, Dave" <[email-masked]>
Date: Mon, 6 Jul 2009 14:18:40 -0700

#1: (5.5.1.3) Binary encoding of IceAttrs for fulfilling IceCandidate

mentioned in draft-ietf-p2psip-base-02

The IceAttrs is a customized, binary encoding of the candidate

specified for ICE [I-D.draft-ietf-mmusic-ice] and ICE-TCP

[I-D.draft-ietf-mmusic-ice-tcp].  This customized version drops

the following fields found in ICE:

o foundation: There is only one media in use for the RELOAD usage of ICE.

  All candidates will have either a different type, host candidate, STUN

  server, or protocol.  There will not be any candidates to freeze when

  ICE starts.

o ice-mismatch: RELOAD will prioritize and take TCP transport candidates

  before UDP transport candidates.

o remote-candidate: ICE restart not supported.

o component: Same reason as foundation.

The candidate attributes TLV structure below is extensible enough to

incorporate new formats for candidates as well as extensions that all

nodes may not support.

struct {

  uint16                IceAttrType; /* CandidateAttrTypeEnum */

  uint16                IceAttrLength;

  uint8                 IceAttrPayload[IceAttrLength];

} IceAttrs;

The supported ranges for CandidateAttrType are:

o   0 through 127: Comprehension required ICE attributes.

                   A recipient must respond with an error to the

                   ATTACH, if it does not understand these attributes.

o 128 through 255: Comprehension optional ICE attributes.

                   A recipient may safely ignore these attributes

                   if it does not understand them.

The first three definitions within the comprehension-required

range are below.  There are no comprehension-optional attributes

defined in this document.

enum {

  no_next_attr                {0},

  ice_base_cand_attr          {1},

  rel_addr_cand_attr          {2}

} IceAttrTypeEnum;

The definition of the first attribute is the base candidate

(ice_base_cand_attr) that denotes the start of a new candidate

in the sequence of candidate in the payload.

enum {

  reserved_transport          {0},

  tcp_simultaneous_open       {1}, /* tcp-so */

  tcp_active                  {2}, /* tcp-act */

  tcp_passive                 {3}, /* tcp-pass */

  udp                         {4}

} TransportEnum;

enum {

  reserved_candidate          {0},

  host_candidate              {1}, /* host */

  srflx_candidate             {2}, /* srflx */

  prflx_candidate             {3}, /* prflx */

  relay_candidate             {4}  /* relay */

} CandidateEnum;

struct {

  TransportEnum         Transport;

  CandidateEnum         CandidateType;

  uint32                Priority;

  IpAddressPort         ConnectionAddressPort;

} IceBaseCandAttr;

Reflexive and Relayed candidates must have a rel-addr attribute

that follows them that is defined below for the rel_addr_cand_attr.

struct {

  IpAddressPort         RelAddressPort;

} RelAddrCandAttr;

Enhancement to AttachReqAns

         struct  {

           opaque                  ufrag<0..2^8-1>;

           opaque                  password<0..2^8-1>;

           uint16                  application;

+          uint16                  ice_attrs_length;

           opaque                  role<0..2^8-1>;

-          IceCandidate            candidates<0..2^16-1>;

+          IceAttrs                ice_attrs[ice_attrs_length];

         } AttachReqAns;

[Note: Tried to reuse layout schema in draft-ietf-p2psip-base-02]

[Problem: Attach-Lite's use of ICE-Lite is not supported in

draft-ietf-mmusic-ice-tcp-07.  That document requires the Attach-Lite

recipient proceed with ICE not ICE Lite if there are TCP candidates.

The intended behavior is for Attach-Lite to use RFC4145 instead of

ICE-Lite for TCP connections.]

#2: (9.5 & 9.9) JoinReq, JoinAns, and Leave layouts for overlay_specific_data

struct {

  AttachReqAns          join_ice_attrs;

} ChordJoinReq;

struct {

  AttachReqAns          join_ice_attrs;

} ChordJoinAns;

Thanks,
Dave

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 6 Jul 2009 17:30:21 -0400 (EDT)

Hi Dave,

Thanks for your suggestion. Indeed, ICE encoding needs an update and we 
are hoping to update it in the next version of the I-D.

Regards,
Salman