|
Hi all,
Very interesting.
For the real implementations, I think we have to
meet the scenarios that MS-SPRing is used in GMPLS networks, because
the different services need different QoP. Therefore, how to deal
with the issues about the interworking between GMPLS R&P and MS-SPRing
protection is very important, e.g., time-slot continuity and GMPLS control plane
should know when to trigger recovery or not as soon as possible (for
example, GMPLS control plane should not trigger recovery when MS-SPRing has
the protection capability, on the other hand ,GMPLS should trigger recovery ASAP
when there is no protection capability for MS-SPRing).
I agree with Diego that we should resolve these
issues from the GMPLS/CCAMP perspective.
Thanks
Fatai
Advanced Technology Department
Wireline Networking
Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian,
Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax:
+86-755-28972935
----- Original Message -----
Sent: Thursday, April 16, 2009 3:43 PM
Subject: RE: Generalizing WSON
information...
Hi all,
I think
that this is an interesting topic to move on, may be this time we can solve
the issue of MS-SPRing interworking with GMPLS control plane that we were able
to solve some times ago.
May be we can resume the ID about the
MS-SPRing we did some time ago and try to elaborate a
generalization.
BR
Diego
__________________________________________
Diego
Caviglia
Strategic Product Manager
Broadband Networks, PL Broadband
Optical Network
Ericsson Telecomunicazioni S.p.A. (TEI)
Via A. Negrone
1/A
Office: +39 010 600 3736
16153, Genova,
Italy
Fax: +39 010 600 3577
Block E Level
4
Mobile: +39 335 7181762
www.ericsson.com
diego.caviglia@ericsson.com
This
communication is confidential and intended solely for the addressee(s). Any
unauthorized review, use, disclosure or distribution is prohibited. If you
believe this message has been sent to you in error, please notify the sender
by replying to this transmission and delete the message without disclosing it.
Thank you.
________________________________
> -----Original
Message-----
> From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On Behalf
> Of Greg Bernstein
>
Sent: mercoledì 15 aprile 2009 19.02
> To: julien.meuric@orange-ftgroup.com
>
Cc: ccamp@ops.ietf.org
>
Subject: Re: Generalizing WSON information...
>
> Hi Julien,
interesting point. It did seem like older SDH equipment did
> have a
"time-slot continuity constraint", but I never directly dealt
> with
those systems. There was some work a while ago on MS-SPRing (Diego?).
>
Maybe we need to think up a level, as you said in the usual GMPLS,
MPLS
> cases full label swapping is a typical capability. Should we be
explicit
> in the WSON case (maybe with the connectivity matrix) in
indicating that
> this may or may not be the case? Right now we are
being implicit about
> this lack of wavelength (label) conversion
capability.
>
> The notion of the shared wavelength converter
pools and the accompanying
> details seem very WSON specific. But the
fact that a switch or mux can't
> perform label exchange seems a fairly
general notion that we could group
> with other generalizable
information...
>
> Best Regards
>
> Greg
>
> julien.meuric@orange-ftgroup.com
wrote:
> > Hi Greg.
> >
> > Just a small comment on
Wavelength Converter Pool in section 3.2. In
> some other GMPLS
contexts, this may be modelled as a label swapping
> capability, which
is a common enough to be considered as "Generalizable"
> (it's even a
typical case that becomes an exception due to our label
> continuity
constraint). However, as for several other parameters, I don't
> think
there is an actual need for it (this is already the default); but
>
maybe we could imagine some MS-SPRing operations in SONET/SDH.
>
>
> > Regards,
> >
> > Julien
>
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of Greg Bernstein
>
> Sent: Tuesday, April 14, 2009 6:32 PM
> > To: ccamp
> >
Subject: Generalizing WSON information...
> >
> > Hello
fellow CCAMPers, at the 74th IETF meeting in San Francisco the
> >
question
> > came up as to what if any of the WSON path computation
information model
> > would
> > be useful in other
technologies. Below is a first attempt at such an
> >
assesment
> > based on the current version of
draft-ietf-ccamp-rwa-info-02.txt.
> > Existing GMPLS
> >
standard information is not included.
> >
> > From
section 3.2 Node Information:
> >
> > Switched Connectivity
Matrix: Generalizable:Yes. This can be used to
> > model any
>
> type of asymetrical switch in any technology. Caveat: Besides optical
is
> > there
> > any current products that can make use of
this?
> >
> > Fixed Connectivity Matrix: Generalizable: Yes.
This can be used to model
> > fixed
> > connectivity between
ports. Caveat: Is there any need outside optical?
> >
> >
Wavelength Converter Pool: Generally useful: No. This is very
>
application
> > specific to optical switching systems.
>
>
> > From section 3.3 Link Information:
>
>
> > Switched and Fixed Port Wavelength (label) Restrictions:
Generally
> useful: I
> > don't think so but open to examples.
These constraints must be shared in
> the
> > WSON case for two
reasons: (a) the wavelength continuity constraint
> requires
>
> global label assignment, (b) WSON devices present many different
types
> of
> > wavelength constraints. Note that without
requirement (a) then (b)
> > doesn't need
> > to be shared
since local label (wavelength) assignment would suffice.
> >
>
> From section 3.4 Dynamic Link information
>
>
> > Available Wavelengths (labels): Generally useful? We need
detailed
> > wavelength
> > availability information due to
the wavelength continuity constraint.
> > Way back
> > in
the old days many of us implemented bit maps to track SONET/SDH time
>
> slots
> > but this never made it into the standards. Any
interest in that now?
> Other
> > examples?
>
>
> > Shared Backup Wavelengths (labels): Similar to the above but
used in
> > efficient
> > shared mesh backup path
computation.
> >
> > From section 3.5 Dynamic Node
Information
> >
> > Wavelength Converter Pool Status: Not
generally applicable. Too
> application
> > specific.
>
>
> > Comments appreciated
> >
> > Greg
>
>
> >
>
> --
>
===================================================
> Dr Greg Bernstein,
Grotto Networking (510) 573-2237
>
>
|