Subject: RE: doubts

From: [email-masked]
Date: Fri, 17 Dec 1999 10:14:53 -0600

From: EXT Wang Shiming [mailto:[email-masked]]
> 
> Hi, all:
>        In Label Range Response Msg of 
> "draft-ietf-gsmp-02.txt", there is 2 field:
> 	Remaining VPIs
>    	Remaining VCIs
> What's its meaning?Suppose a port has 50 VPCs , eash has 1024 
> VCI label; Now
> 	10 VPCs is unused;
> 	20 VPCs used 512 VCIs;
> 	20 VPCs used 1000VCIs;
> Then how to fill fields: Remaining VPIs and Remaining VCIs?

the fields do not pertain to the allocation of labels to
connections but rather to the (atm port type specific)
business of establishing, at port configuration time, 
labels, or ranges of labels, as available for switching.

these fields are based on certain assumptions regarding
the structure of the label lookup memory in an atm cell
processor.

1. it is assumed that the processor fully decodes all 12 
bits of the vpi and can either vpc switch in the vpi or
can assign at least one vci within on the vp for vcc
switching.

2. the cell processor cannot fully decode the 16 bit vci 
field on all vpis.

3. the cell processor has a limited memory which is 
divided into n table entries, each of which can be
used to decode and translate one vci.

4. chunks of contiguous table locations can be assigned
to translate chunks of contiguous vci space on arbitrary
vpis.

based on those assumptions, remaining vpis indicates
the number of entries in the vpi table that remain
unallocated for either vpc or vcc witching. remaining
vcis indicate the number of entries in the vci table 
that remain unallocated for vcc switching in any of
the vps.

(on a separate issue, i think that the above assumptions
are probably adequately general and widely applicable to
atm switches for our purpose with gsmp. i'd be interested 
to lean of anyone's experience in putting gsmp on atm 
switches that are significantly different.)

> Actually there are lots of errors and vague places in 
> "draft-ietf-gsmp-02.txt", I suggest gsmp working group to 
> arrange some people to correct them.

yes. the tidying up of the draft in terms of error codes,
message summaries and such has been left to the end of 
this round. the time has indeed come to deal with this.
<grin> did i correctly understand that you have volunteered
to organise some folk to provide text that sorts this out? 
this is very good news. thank you.</grin>

c u
tom