Subject: [ippm] OWDP coding proposal

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 18 Apr 2001 16:25:23 +0200

Dear IPPMers,

below you'll find two proposals how to modify the coding of OWDP messages.
Please don't expect immediate replies on comments from me, I'll be out of
office until 25. April.
I hope the stuff below is readable when you get it...

Regards, Rüdiger

-------Content starts here----------

1 Accept/Reject Indication
The coding of parameters should be non-ambiguos to leave no room for 
interpretations. 

+-+-+-+-+-+-+-+-+
|   Accept      |
+-+-+-+-+-+-+-+-+

Example of OWDP-02.txt:

   A zero value in the Accept field means that the server accepts the
   [request] and is willing to conduct further [actions].  Any
   non-zero value means that the server does not accept the
   [request] provided by the client or, for some other reason, is
   not willing to conduct further [actions] in this OWDP-Control
   session.

Proposal

   A zero value in the Accept field means that the server accepts the
   [request] and is willing to conduct further [actions].  A
   00000001 value means that the server does not accept the
   [request] provided by the client or, for some other reason, is
   not willing to conduct further [actions] in this OWDP-Control
   session. All other settings are reserved.

2 Request Session / test traffic profile
The Request Session message should contain a generic Test Traffic Profile 
parameter leaving room for future definitions of test traffic profiles.

Definition of OWDP-02.txt (Request Session message)

        0                   1                   2                   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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      1        |IPVN-S | IPVN-R| Conf-Sender   | Conf-Receiver |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        \                                                               /
        /                                                               \
        \                                                               /
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                        SID (16 octets)                        |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Inv-Lambda                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Packets                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        \                                                               \
        /                                                               /
        \                                                               \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposal

        0                   1                   2                   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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      1        |IPVN-S | IPVN-R| Conf-Sender   | Conf-Receiver |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        \                                                               /
        /                                                               \
        \                                                               /
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                        SID (16 octets)                        |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    Session Profile TLV                        |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Packets                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        \                                                               \
        /                                                               /
        \                                                               \
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note: This modification is based on the assumption that TLV coding will be 
applied for the OWDP protocol. During the 50th IETF meeting Joan 
Cucchiara (?) of BRIXnet volunteered to make a suggestion to this regard. 

Session Profile TLV

        0                   1                   2                   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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Session Profile  (TBD)   |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Profile Identifier         |            Reserved           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Profile Parameters                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length is a 16 bit Unsigned Integer indicating the length of the Session 
Profile TLV as an integer multiple of octets (or 32 bit words, whatever is 
preferred by the WG) including the TLV name and length 32 octets.

Profile Identifier is a 16 bit field indicating the type of profile of the 
test traffic for the session.
Deafault:
0000..0000		Contiguous poisson profile.

All other settings are reserved.

Contiguous poisson profile parameters

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Inv-Lambda                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Definition of the parameter see OWDP-02.txt.

Rules for Session Profile TLV definitions
An OWDP Session Profile other than the defaultprofile MUST be defined by a
separate IETF document. The profile parameters MUST provide the complete 
information to non-ambiguosly identify the characteristics of a test-stream
to be used for a session.

Note that RFC1889 (RTP) choose a similar principle to provide flexibility 
for future extensions. 
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: stanislav shalunov <[email-masked]>
Date: 23 Apr 2001 15:05:55 -0400

> below you'll find two proposals how to modify the coding of OWDP messages.
[...]
> 1 Accept/Reject Indication
[...]
> 2 Request Session / test traffic profile
[...]

Ruediger,

The first change makes a lot of sense and will go into the document
(so that the code specified now can become a catch-all error code
later).

The second change is more complex and I'd like to hear what the other
people who wanted a similar approach actually want before/if we put
any particular scheme in to replace what we have.  Joan and Kaynam
said there will be something on the list that makes explicit their
suggestions (hint, hint).

Thanks for the contribution!

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

This message is designed to be viewed at 600 dpi.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm