RE: GSMPv3 & L2C

Hi Avri
  My preference would be to not impose this restriction (1 technology
specific TLV per event message). However, given this restriction,
technology specific extensions will need to nest multiple sub-TLVs in
the extension block. The 8 bit "Block Length" is probably not enough. 16
bit length field would most likely be sufficient. I guess one could
probably use a different instance of the event message once the limit is
reached, but that calls for little more code complexity.=20

-Sanjay       =20


         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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vers  |  Sub  | Message Type  | Result|        Code           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Partition ID  |            Transaction Identifier             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|      SubMessage Number      |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Port                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Port Session Number                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Event Sequence Number                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|S|x|x|                                                       |
      +-+-+-+-+                     Label                             |
      ~                                                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x|x|x|x|x|x|x|x| Message Type  |   Tech Type   | Block Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         Extension Value                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>-----Original Message-----
>From: [email protected] [mailto:[email protected]]On Behalf Of
>avri doria
>Sent: Thursday, March 10, 2005 10:37 AM
>To: [email protected]
>Subject: Re: [GSMP] GSMPv3 & L2C
>
>
>Hi,
>
>Sorry I did not answer this sooner.  My inclination would be to=20
>maintain a single extension TLV per technology type and allow the=20
>technology specific protocol extension to nest sub-TLVs within that=20
>structure.
>
>My reasons are that I think it would be simpler for the base protocol=20
>implementation and would organize the IANA effort for defining new TLV=20
>fields with more flexibility for the extension writer; i.e each=20
>technology specific extension defines the fields it needs and does its=20
>own IANA registrations.
>
>My goal with the base has to keep it as simple as possible so that=20
>hoepfully once it get back on the standards track, it can remain=20
>unchanged while the technology specific efforts continue independently.
>
>I would be interested in hearing other people on this list comment on=20
>this issue.
>
>thanks
>a.
>On 14 feb 2005, at 16.08, Sanjay Wadhwa wrote:
>
>> Section 3.1.4 in the GSMPv3 draft describes extension TLVs.=20
>There is a=20
>> restriction of "at most one extension TLV per message type".=20
>Is there=20
>> a particular reason for this restriction ? There might be=20
>cases where=20
>> a particular technology needs more than one such (optional) TLV in a=20
>> message. One option could be to have the "extension value"=20
>be composed=20
>> of multiple sub-TLVs (with their own well defined format).=20
>But, it is=20
>> simpler to allow multiple top level TLVs. Based on the=20
>"length" in the=20
>> GSMP message header and the "length" in each TLV, the=20
>parsing is not a=20
>> problem. For sanity check number of TLVs in the message can be=20
>> included in the message. The device that does not understand a=20
>> particular TLV can silently ignore the TLV and continue on.
>> In context of L2C this is needed for a BRAS (controller) to=20
>configure=20
>> line characterstics of a DSL line on a DSLAM. There is more than one=20
>> parameter that can be configured (multiple, optional TLVs in=20
>the port=20
>> management message seems like an appropriate way to implement this=20
>> functionality). Any thoughts on not having the restriction=20
>of a single=20
>> "extension" TLV per message type ?
>>
>> Thanks
>> -Sanjay
>>
>>
>>
>>
>>
>> _______________________________________________
>> GSMP mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/gsmp
>>
>
>
>_______________________________________________
>GSMP mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/gsmp
>