Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG dcoument status]

[Maarten Vissers <[e-mail]>]

ASON supports both the peer and the overlay model. When the interconnect is a
NNI (trust relation) there is a peer relation, when there is a UNI (no trust
relation) there is an overlay.

ASON defines its connection setup within the scope of one layer network (e.g.
VC-4, ODU3). If e.g. a Router with a VC-4 port needs to set up a VC-4 trail to
support an IP link, the router can have a VC-4 UNI or VC-4 NNI into the network. 
- For the VC-4 UNI case, the router "includes" a VC-4 Calling/Called Party Call
Controller (CCC) function (intra-layer overlay model support). 
- For the VC-4 NNI case, the router "includes" a VC-4 Connection Controller (CC)
function (intra-layer peer model support).

The above addresses intra-layer overlay/peering situations. 
There is also the inter-layer overlay/peering case. 

The network engineering process (for inter-layer interactions) is currently
under study within ASON. One can consider the following for the moment: when the
network engineering process within the IP layer network decides it needs an
additional IP Link, or an extension of an already existing IP Link between nodes
X and Y, then the IP Network Engineering Controller may issue a VC-4 call
request to the VC-4 Network Call Controller (NCC). The endpoint of the call are
a VC-4 SNP (Pool) representing a VC-4 port (group) in X and a VC-4 SNP (Pool) in
Y (case of inter-layer overlay model). 
Not yet considered, but not impossible would be that the IP network engineering
controller could "include" a VC-4 CC (case of inter-layer peering model).
Whether this is more theoretical than practical is not the issue of this thought
here.

Regards,

Maarten

> Osama Aboul-Magd wrote:
> 
> Dimitri,
> 
> You can also look at GMPLS as a tool kit that is applicable to different
> models, ASON being one of them.
> 
> Yes, ASON is an overlay model. There is no reason why GMPLS based protocols
> for signaling and routing could not be used for ASON control plane
> implementation. Your statement regarding "restricting" routing information
> between client and server networks only reflects your preference to deploy a
> peer model. This is fine, but do not impose artificial requirements that
> wouldn't allow the application of GMPLS protocols to other models. The last
> time I looked at the IP over optical framework, overlay was one of the models
> discussed.
> 
> I have been saying in a number of presentations to the IPO WG (in the context
> of "draft-ietf-ipo-ason-01.txt") that ASON and GMPLS are complementary in the
> sense that GMPLS protocols could be used for ASON control plane realizations.
> The latest activities at the ITU just prove that.
> 
> Regards;
> 
> Osama Aboul-Magd
> Nortel Networks
> P.O. Box 3511, Station "C"
> Ottawa, ON, Canada
> K1Y - 4H7
> Tel: [phone]
> e.mail: [e-mail]
> 
>  -----Original Message-----
> From:   [e-mail]
> [mailto:[e-mail]]
> Sent:   Tuesday, February 26, 2002 8:43 AM
> To:     Wijnen, Bert (Bert)
> Cc:     Mannie, Eric; 'Mak, L (Leen)'; [e-mail]; Kireeti Kompella
> Subject:        Re: ITU-T Communications to IETF CCAMP WG [ was RE: WG
> dcoument status]
> 
> Bert,
> 
> i see many issues, the statement refers to "call" while from the
> ietf terminology, this term is referred to as "session"; as such
> it could be appropriate from our side to review the statement
> made in the "ITU liaison" because the proposed separation plugs
> a "telephony-oriented" model (or telephony-like model) to a data
> /circuit switched oriented network - but not with "64kb" - one
> speak here about connections from 51.84 Mb (more precisely the
> payload of a C3 is 48384 kbps) to 2.5, 10 or even 40 Gbps !
> This separation (adapted for public telephony network) is also
> constructed on an assumption that there is no control plane
> protocol as we have today with GMPLS protocols but that connection
> signalling is performed by the transport plane (using embedded
> signalling) or through management plane. So there is an under-
> lying fundamental question isn't the G.ASON model only a "public
> overlay model" and then we have to ask ourself if the scope of
> GMPLS has to be adapated/restricted to such public networks
> using an overlay control plane inter-connection: imho, clearly no
> but what could be considered is a "GMPLS profile" for G.ASON.
> 
> Moreover this "assumption" resulted to the fact that G.ASON is
> based on a fundamental assumption: no routing information exchange
> between the client and server layer. GMPLS does not have such
> stringent restriction. Consequently, this makes the separation
> call/connection (while mandatory per requirement in the stringent
> G.ASON model) not at all mandatory in the IETF scope since the
> "routing exchanges" fulfill the role played by the call operation:
> the source knows the status and the availability of the set of
> destinations it can reach. Since routing is one of the foundation
> of any data network, i think we should probably also discuss if
> this separation is adapted for other types of GMPLS networks. In
> brief, i don't think we have to restrict the ubiquity of the GMPLS
> protocol suite.
> 
> Hope this clarifies,
> 
> regards,
> - dimitri.
> 
> "Wijnen, Bert (Bert)" wrote:
> >
> > Erik et all, the "official communications from the ITU" are
> > listed under the Liaison Statements on the IETF Web Page.
> > The page is at: http://www.ietf.org/IESG/liaison.html
> >
> > If you see trouble/issues with any of those, pls let WG chairs and
> > ADs know, so we can take action.
> >
> > Bert
> 
> --
> Papadimitriou Dimitri
> E-mail : [e-mail]
> Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
> Address: Alcatel - Optical NA, Fr. Wellesplein, 1
>          B-2018 Antwerpen, Belgium
> Phone:   Work: [phone] - Home: [phone]