Subject: Re: [ippm] OWDP coding proposal

From: Steven Van den Berghe <[email-masked]>
Date: Wed, 02 May 2001 17:45:16 +0200

Hi IPPMrs,

Sorry for this late reply, but things have been quite busy (which is probably
the case for all of you :) ). I was previously one of the people in favour of
the addition of a extensible TLV-system to the OWDP-control protocol. Here is
a small proposal (very drafty) for obtaining this feature.

Modified  request-session-message

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |              Sender Address (cont.) or Unused                 |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Receiver Address                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |              Receiver Address (cont.) or Unused               |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Sender Port          |         Receiver Port         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                        SID (16 octets)                        |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Packets                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Padding Length                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           Start Time                          |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                       Optional TLV's                          |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Observe that, due to the fact that the draft specifies that OWDP-control goes
over TCP, we know the size of the packets, hence we also know how many TLVs
are following. I don' seem to find a reason for adding padding to the
control-protocol (of course, i'll probably be missing out on something, as
usual).

An example of a possible TLV was already given in Ruediger's mail (i replyed
to this, so it should be somewhere below this text). His lay-out is something
like this:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Session Profile  (TBD)   |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Profile Identifier         |            Reserved           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Profile Parameters                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As you might have noted, i've dropped the type-P-packet classifier. I suggest
to replace it with the following TLV:

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Type-P descriptor  (TBD)   |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Class Identifier           |            Reserved           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Class Parameter                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The class denotes a "characteristic" of the packet like
  - well-known servces
  - DSCP
  - source port
  - ....
A combination of multiple TLV's can be possible.

As i said, this is just a first draft. If the IPPM list likes this, i could
enhance this a bit into a real text (although i would suggest to put specific
TLV definitions in a seperate document).

So, please shoot your comments,

Best regards,
Steven Van den Berghe

"Geib, Ruediger" wrote:

> 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

--
Steven Van den Berghe
[email-masked]
Workgroup Broadband-Networks
Department Information Technology
Ghent University - Belgium
Phone:  +32 (0)9 267 35 86 | Fax  :  +32 (0)9 267 35 99
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
ACSII stupid question, get a stupid ANSI!

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Fri, 11 May 2001 12:26:44 +0200 (CEST)

Ruediger,

I think both suggestions make sense.

Henk

> The coding of parameters should be non-ambiguos to leave no room for 

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445 
The Netherlands                   Mobile: +31.6.55861746  
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)

---

From: Ben Teitelbaum <[email-masked]>
Date: Mon, 14 May 2001 03:39:10 -0400

Ruediger and Henk,

While the generality of Profile Identifier/Profile Parameters is appealing,
I'd rather not achieve generality through indirection and deferral, when we
could do a pretty good job right now. What if we spec'd into the Request
Session message a test packet schedule characterized by the following three
arguments:

1) an arbitrary length packet train schedule {sleep_0, sleep_1, ...}, where
sleep_n is the amount of time session-sender waits between transmitting the 
first bit of the n_th packet and transmitting the first bit of the n+1_th 
packet in the train; each train consists of a single packet followed by as 
many packets as are specified in the schedule and sleep times less than a 
packet transmission time at the session-senders' interface speed are 
assumed to equate to back-to-back test packets;

2) a packet train probability distribution [periodic, Poisson, uniform, ...];

3) an average inter-packet train interval (given as a reciprocle, as in the
current draft);

This is general enough to describe the two in-vogue test stream distributions:

Poisson: {{}, Poisson, Inv-Rate}
Periodic: {{}, periodic, Inv-Rate}

as well as the packet pair versions of these:

Poisson-Pair: {{0}, Poisson, Inv-Rate}
Periodic-Pair: {{0}, periodic, Inv-Rate}

or weird repeating things things like:

{{10, 20, 40, 80, 160}, periodic, 5000}

or even an arbitrarily weird distribution specified by a single long packet
train schedule.

Note that the server is free to reject session requests that impose
unacceptibly large memory requirements on Session-Senders or appear to be
malformed: {{1 min}, Poisson, 0.5 sec}.

So, could something like this work?

-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum
                           -   Advanced Network & Services, Inc.
                           .   Internet2

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Mon, 14 May 2001 13:41:45 +0200 (CEST)

On Mon, 14 May 2001, Ben Teitelbaum wrote:

> could do a pretty good job right now.

Can't we do both: use Ruediger's proposal for a profile identifier and put
a number of currently popular cases in the draft, reserving the others? 

Henk

---

From: Ben Teitelbaum <[email-masked]>
Date: Mon, 14 May 2001 09:46:57 -0400

> a number of currently popular cases in the draft, reserving the others?

Yes, I suppose we could. If we did so, I'd advocate defining a profile
identifier for an explicit test packet schedule specified in the Profile
Parameters area. 

-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum

---

From: stanislav shalunov <[email-masked]>
Date: 14 May 2001 08:29:22 -0400

> Modified  request-session-message

[Append field called "Optional TLV's" and remove Type-P descriptor to
existing Request-Session command format.]

> Observe that, due to the fact that the draft specifies that
> OWDP-control goes over TCP, we know the size of the packets, hence
> we also know how many TLVs are following. I don' seem to find a
> reason for adding padding to the control-protocol (of course, i'll
> probably be missing out on something, as usual).

Steven,

Just a quick note for now:

1. We don't know when to stop reading the current command from the TCP
   connection.

2. Zero padding isn't used to indicate the end of something (end is
   determined from known fixed size); it's to ensure message integrity
   in authenticated and encrypted modes.

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

"Hey!  Who took the cork off my lunch?!"               -- W. C. Fields
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm