The MPLS WG Archive

[Eve Varma <evarma@lucent.com>]

Hi all,

Watching the various emails regarding the GMPLS drafts, I see several
issues being raised related to some concerns that service provider
requirements haven't been sufficiently reflected in the GMPLS signaling
specifications - or at least, not been tested against.  (An initial set
of requirements was provided by BT on
Considerations on the development of an Optical Control Plane -
http://search.ietf.org/internet-drafts/draft-freeland-octrl-cons-01.txt.
Monica has mentioned other currently available sources of service
provider requirements as well, such as the Carriers Optical Services
Framework and Associated Requirements for the UNI, developed in the OIF
and submitted to T1 and ITU-T.  Some requirements were also submitted
earlier in the draft Requirements on the ASON UNI -
http://search.ietf.org/internet-drafts/draft-lin-mpls-ipo-ason-uni-00.txt.
)

For example, assuring separation of the control plane from the data
plane continues to arise - the GMPLS architecture document mentions this
separation, but it's not clear how the GMPLS signaling specifications
reflect the implications of this decoupling.  This is best illustrated
in the handling of control plane failures.  In particular, what happens
to established circuit connections if the control plane fails? If the
control plane recovers, how do we sync the connection state?  As an
example, from RSVP RFC: "RSVP takes a "soft state" approach to managing
the reservation state in routers and hosts. RSVP soft state is created
and periodically refreshed by Path and Resv messages. The state is
deleted if no matching refresh messages arrive before the expiration of
a "cleanup timeout" interval." This means that if for whatever reason
control messages are lost, the associated data paths will be released. 
Thus there is strong failure correlation between the control plane and
data plane, which is inconsistent with the GMPLS architecture document,
and also results in tearing down optical connections resulting from even
temporary failures in the control plane.

I also understand the other comments from Hirokazu and Shehzad re
exclusion of NSAP, having been at the last OIF meeting where there was
considerable and spirited discussion of this issue.  The current GMPLS
architecture document specifically excludes NSAP, and from the last OIF
meeting 6 out of 12 operators discussing this issue felt there was some
need to support NSAP addressing. 

Given that the Requirements Design Team will be starting shortly, I
concur with Yuri's suggestion for inclusion of a clear statement of what
is - and isn't - covered in the GMPLS Signaling Description, RSVP
Extensions, LDP Extensions drafts.   A suggestion for such text is
provided below (the intro will need to be tailored to each draft):

"Overall, the objective of Generalized MPLS is to adapt MPLS signaling
and other protocols to enable their applicability to various switching
technologies.   A key motivating application has been applicability to
support a distributed control plane for various circuit-switching
technologies.   The signaling specifications contained within the these
drafts offer a starting point towards this goal; their current scope and
applicability, and areas for further assessment, are summarized below: 

These drafts provide some extensions to traditional MPLS signaling and
the basic signaling mechanisms provided in RSVP and LDP Ids (RFCs and
standard track documents) have not been modified.   It is noted that
MPLS signaling has been designed with a focus upon packet-switched
network based applications, utilizing  requirements and architectural
constructs suitable for such applications.   There may be significant
distinguishing characteristics with regard to requirements and
architectural considerations  for a distributed control plane that
supports circuit-switched network applications.  One well acknowledged
instance involves the decoupling of the control plane from the data
plane.  Such differences may have substantive impact on the signaling
mechanisms, the details of which require further study.  In addition,
upon further study of operational requirements and circuit-switching
technology specific aspects, further signaling extensions may be
required.

These drafts are focussed upon intra-area signaling interfaces, and do
not address issues and considerations related to other domains of
usage.   Applicability to inter-area and inter-domain interfaces
requires further study."

Hope this helps us move forward.

Cheers,
  Eve

itu

shehzad.mirza@bt.com wrote:
> 
> Hi,
> 
> I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS signalling
> drafts.
> 
> (1) Decoupling of the control plane from the data plane should be clearly
> stated.
> 
> This decoupling clearly has an impact on how the protocols should be defined
> to cope with control plane failures.
> 
> (2) Exclusion of NSAP
> 
> The GMPLS architecture document, (which logically speaking should perhaps
> have been put forward for last call, ahead of the functional description)
> explicitly excludes NSAP.  NSAP addressing is used within SDH/SONET
> communications channels (DCC bytes) therefore the use of alternative
> addressing within the same channels may have an adverse effect on
> interworking with legacy equipment, particularly with regard to management.
> This raises the general concern of what level of compatibility is
> required/desired with legacy SDH/SONET equipment.  This debate whilst likely
> to be contentious, is unavoidable as the interworking of control plane,
> management plane and transport will have a direct impact on how this
> equipment is deployed and the economics of whether such deployments will
> ever pay off.
> 
> (3) Requirements from both security and OSS has not been discussed fully
> yet.
> 
> Security concerns have not been fully addressed, particularly at the
> architectural level.  The use of separate control network may necessitate
> the need for 24 hour staff to protect against 'Denial of Service' attacks as
> currently happens for IP router networks.  The interaction between the
> management plane and control plane need to be addressed, for example it is
> undesirable to have multiple alarms generated when circuits are created and
> torn down otherwise the management of a large scale network will become
> impossible.  Discussions on service aspects need to take place, otherwise
> the adoption of GMPLS equipment may be hampered, by these (solvable)
> concerns.
> 
> Best regards
> 
> Shehzad Mirza
> 
> 
> 
> > -----Original Message-----
> > From: Hirokazu Ishimatsu [SMTP:hirokazu@japan-telecom.co.jp]
> > Sent: 29 May 2001 02:46
> > To:   George Swallow; ccamp; mpls
> > Cc:   ip-optical; tsg15q11; tsg13q10
> > Subject:      [IP-Optical] RE: GMPLS Last Calls
> >
> > Hi,
> >
> > From a carrier's perspective, my concerns about GMPLS signaling drafts
> > are as follows:
> >
> > (1) Decoupling of the control plane from the data plane should be clearly
> >      stated.
> > (2) Exclusion of NSAP
> > (3) Requirements from both security and OSS (Operating Support System)
> >      has not been discussed fully yet.
> >
> > Best regards,
> > Hirokazu Ishimatsu
> > Japan Telecom
> >
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> > > Behalf Of George Swallow
> > > Sent: Tuesday, May 15, 2001 2:52 AM
> > > To: ccamp@ops.ietf.org; mpls@uu.net
> > > Subject: GMPLS Last Calls
> > >
> > >
> > > This message initiates a last call on four GMPLS drafts.  The last
> > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > >
> > > The drafts are:
> > >
> > >     1.  Generalized MPLS - Signaling Functional Description
> > >
> > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > >
> > >
> > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > >
> > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > >
> > >
> > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > >
> > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > >
> > >
> > >     4.  GMPLS Extensions for SONET and SDH Control
> > >
> > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > >
> > >
> > > The last call closes May 29, 12 pm GMT.
> > >
> > >
> > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > >
> > >
> > > ======================================================================
> > > George Swallow       Cisco Systems                   (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> > >
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > IP-Optical mailing list
> > IP-Optical@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> 
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical