Subject: RE: GSMP Connection Management

From: [email-masked]
Date: Fri, 15 Oct 1999 18:19:39 +0300

From: EXT Constantin Adam [mailto:[email-masked]]
> 
> I have the following questions/suggestions about the GSMP connection
> management messages:
> 
> 
> 1. GSMP has a Create Virtual Path message (message 26). However, I
>    could not find a way to remove a Virtual Path. What is the
>    procedure to follow to remove a Virtual Path?

the delete branches message is used to delete a
virtual path. 

> 2. Many switches support up to a maximum number of multicast
>    connections. Is there any way to find out, using GSMP, what is the
>    maximum number of multicast connections the switch can support? I
>    think this is a useful feature. Also, some switches allow to choose
>    the number of multicast connections that can be setup on the
>    switch.

this is a good point. the trouble here is finding the
right way to express such limits. atm switches have a
wide variety of multicast limitations. some have the
limit you mention. others have different limits
including: max m/c connections per port, or per module,
max m/c leaves per connection, max m/c leaves per port,
etc... it will not be trivial to define a message that
will be expressive enough to capture the limitations
of a wide range of switches.

gsmp does have a fairly wide selection of multicast
failure responses. these can be quite expressive and
allow the controller to learn about the switches
limits, albeit a posteriori.

> 3. Finally, some ATM switches (for example from Fore Systems) allow to
>    setup a VP origination and a VP termination. I think GSMP should
>    provide a similar capability.

it does. since gsmp has no interest in atm's control 
or management plane it fulfills this requirement by
allowing cell switching on the vpi+vci. i wrote a
message to this list on the topic in august which 
i've included below for you.

c u
tom

> -----Original Message-----
> From: EXT [email-masked] [mailto:[email-masked]]
> Sent: 19 August, 1999 1:33 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft of draft-ietf-gsmp-msf-response-00.txt
> 
> 
> From: EXT Joachim Buerkle [mailto:[email-masked]]
> > 
> > >>Requirement #39:       The SCI shall support the 
> > termination of virtual paths
> > (splitting a VP into VCs) as per I.311.
> > >>GSMPv3 compliance:     E. requirement needs further explanation.
> > 
> > ST: In my view GSMP supports this, since I think this is 
> > related to the following
> > text in
> > [I.311] Recommendation I.311 (08/96) - B-ISDN general 
> network aspects
> > (http://www.itu.int/itudoc/itu-t/rec/i/index.html)
> > "When VCs are switched, the VPC supporting the incoming VC 
> > links must be terminated
> > first and a new outgoing VPC must be created. Cell sequence 
> > integrity is preserved as
> > defined in clause 2/I.150 by the ATM layer for cells 
> > belonging to the same VPC. Thus
> > cell sequence integrity is preserved for each VC link within a VPC."
> > 
> 
> 
> i think gsmp supports this. since gsmp is not directly
> interested in any signalling issues there is only the
> cell switching to consider. gsmp supports vpc termination
> in exactly the same way that it supports cell switching
> on the vpi/vci. gsmp makes no distinction here.
> 
> for example, lets take a simple scenario. let's use 
> a terminology of (port:vpi:vci->port:vpi:vci) to
> represent gsmp branches. now, let's add the
> following:
> 
>   (2:0:40->5:20:1)  and  (5:20:1->2:0:40)
>   (7:0:51->5:20:2)  and  (5:20:2->7:0:51)
>   (8:0:77->5:20:3)  and  (5:20:3->8:0:77)
> 
> at the switch adjacent to this one's port 5 we
> switch the vpi=20 as a vpc, e.g. we add vpc
> branches (5:20:*->12:18:*) and (12:18:*->5:20:*). 
> as far as cell switching is concerned we have 
> terminated the vpc. 
> 
> as you can see from this example, from gsmp's
> point of view, vpc termination is no different
> from vcc switching. so while vpc termination is
> not visible in the protocol, it is supported.
> 
> 
> c u
> fsb
>

---

From: Jaroslaw Sydir <[email-masked]>
Date: Mon, 18 Oct 1999 08:41:33 -0700

> limits, albeit a posteriori.

Tom and all. We are doing the final editting of a draft that proposed a
number of GSMP modifications. One of our proposed changes addresses
this problem. We will push the draft onto the mailing list early this week

Regards,
Jerry

--
Jerry Sydir                    phone: +1(650) 938-8066 x102
CPlane Inc.                    fax  : +1(650) 938-8068
5150 El Camino Real Suite B-31
Los Altos, CA 94022