I-D ACTION:draft-ietf-ccamp-gmpls-mln-reqs-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
	Author(s)	: K. Shiomoto, D. Papadimitriou, J. Roux, M. Vigoureux, D. Brungard, E. Oki, I. Inoue, E. Dotaro
	Filename	: draft-ietf-ccamp-gmpls-mln-reqs-09.txt
	Pages		: 25
	Date		: 2008-5-1
	
Most of the initial efforts to utilize Generalized MPLS (GMPLS)
   have been related to environments hosting devices with a single
   switching capability. The complexity raised by the control of such
   data planes is similar to that seen in classical IP/MPLS networks.
   By extending MPLS to support multiple switching technologies, GMPLS
   provides a comprehensive framework for the control of a multi-
   layered network of either a single switching technology or multiple
   switching technologies.
    In GMPLS, a switching technology domain defines a region, and a
    network of multiple switching types is referred to in this document
    as a Multi-Region Network (MRN). When referring in general to a
    layered network, which may consist of either a single or multiple
    regions, this document uses the term, Multi-Layer Network (MLN).
    This document defines a framework for GMPLS based multi-region /
    multi-layer networks and lists a set of functional requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-reqs-09.txt

Internet-Drafts are also available by anonymous FTP at:

I-D ACTION:draft-ietf-ccamp-gr-description-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Description of the RSVP-TE Graceful Restart Procedures
	Author(s)	: D. Li
	Filename	: draft-ietf-ccamp-gr-description-02.txt
	Pages		: 17
	Date		: 2008-5-5
	
The Hello message for the Resource Reservation Protocol (RSVP) has 
   been defined to establish and maintain basic signaling node 
   adjacencies for Label Switching Routers (LSRs) participating in a 
   Multiprotocol Label Switching (MPLS) traffic engineered (TE) 
   network. The Hello message has been extended for use in Generalized 
   MPLS (GMPLS) network for state recovery of control channel or nodal 
   faults.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Fw: I-D ACTION:draft-ietf-ccamp-gr-description-02.txt

Dear CCAMPers,

We just updated the GR-Description draft, there is no technical change in this version. We added some text
to clarify the procedures for multi nodes which are not neighbors restart scenario.

Best regards,

Dan

----- Original Message ----- 
From: <Internet-Drafts <at> ietf.org>
To: <i-d-announce <at> ietf.org>
Cc: <ccamp <at> ops.ietf.org>
Sent: Tuesday, May 06, 2008 6:45 AM
Subject: I-D ACTION:draft-ietf-ccamp-gr-description-02.txt

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
> 
> Title : Description of the RSVP-TE Graceful Restart Procedures
> Author(s) : D. Li
> Filename : draft-ietf-ccamp-gr-description-02.txt
> Pages : 17
> Date : 2008-5-5
> 
> The Hello message for the Resource Reservation Protocol (RSVP) has 
>    been defined to establish and maintain basic signaling node 
>    adjacencies for Label Switching Routers (LSRs) participating in a 
>    Multiprotocol Label Switching (MPLS) traffic engineered (TE) 

Working Group Last Call: draft-ietf-ccamp-gr-description-02

Re: Poll for WG Adoption of Two WSON documents

Hi,

yes support both

I have also few comments on Framework WSON

-  Section 3.3.1
How about using a more generic OXC model? Or may be having a two 
pictures, one with the current ROADM and one with an OXC (degree > 2)?  
For sure the simple ROADM it's the easier to understand but looks to me 
too specific.

The text: "As the degree of the ROADM increases beyond two it can have 
properties of both a switch(OXC)and a multiplexer"
To me looks like the figure 1 has already multiplexing capability 
correct? For example a wavelength entering in what you call an add port 
is multiplexed on a *line* (keeping same terminology of the document) port.

A simple questions on the switching matrix: looks like add/drop ports 
and *line* ports are considered the same in the matrix, correct?

- Section 4.1
About time frame classification: Dynamic, pseudo-static and static. 
While the text explains why an RWA would appreciate some temporal 
information a classification like  "relatively short" or "moderately 
long"  are a bit difficult to understand to me, Long or short are 
compared to what?.

- Section 6 Security
Does it worth a reference to 
http://tools.ietf.org/id/draft-fang-mpls-gmpls-security-framework-01.txt?

- A small ed note: in reference section the [G.994.1] is within both 
normative and informative sub-sections...

Cheers
G

BRUNGARD, DEBORAH A, ATTLABS wrote:
> CCAMP,
>  
> From Philadelphia, we had good support for adoption of two of the WSON 
> documents as CCAMP working group documents:
>  
> - Framework for WSON
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt
>  
> - Lambda Labels
> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt
>  
> Please express your opinions (authors, we welcome your opinion also).
>  
> Thanks,
> Adrian and Deborah

Network modeling & NML group in the OGF

Hi folks,

I've was recently pointed to the WSON list by a colleague, who is 
liaison of the Open Grid Forum (OGF) towards the IETF [1].

The list has no archive, so I may have missed a few topics, but after 
reading the discussion on the difference between OOO and OEO or on 
wavelength versus waveband switching, I think there is a need for an 
explicit multilayer model. The MLN/MRN work at least has a syntax, but I 
  have not seen a formal model.

I'll post this to the CCAMP list rather than the WSON list since it is a 
bit more general.

I just finished my PhD thesis on multi-layer path finding. I'll briefly 
mention this work (I apologize for the shameless plug) and than mention 
was is currently done in the OGF. Let's see if there is some mutual 
interest.

We created a model and syntax called Network Description Language (NDL) 
[2]. A major goal was to enable complex multi-layer path finding, with a 
technology independent algorithm. "Complex" because multi-layer path can 
in fact contain loops [3], which is not possible in single layer networks.

The technology independence (no technology-specific code) means that not 
only the networks are described in an abstract model, but so are the 
different technologies. For example, the path finding "learns" about 
characteristics of WDM by reading a file describing the technology. That 
file contains the different adaptations, layers and label definition (in 
our WDM example file, the labels are floats: the wavelength in nm, and 
the spacings are described as different adaptations. Interestingly it is 
possible to use the same model to make another technology description of 
WDM, for example with or without a group mux sublayer). Of course the 
challenge was to force the different technologies in such a generic 
model. Tagged Ethernet in particular took some effort. One thing that 
worked very well was to distinguish between two different switching 
capabilities: one "switching" for forwarding traffic with the same 
"label" (e.g. wavelength switching without wavelength conversion or 
Ethernet VLANs) and for forwarding while allowing label changes (e.g. 
timeslots in TDM or wavelength conversion).

Beside the model, we create a syntax. Instead, our syntax is based on 
semantic web [4] and RDF. What worked very well was that we could easily 
separate the different subtopics: topologies description, (technology) 
layers, capabilities (such as the ability or inability of a device to 
convert between labels), domain abstraction, physical properties, etc. 
What's more, we could easily combine this information with different 
information such as policy descriptions and pointers to reservation 
systems. We are in the process of combining network description with a 
description of 4K very high definition digital cinema display, media and 
storage) [5], so that a metascheduler not only can take network 
resources but also storage and visualization resources into account.

In case you wonder how our model compares with GMPLS: Jeroen van der 
Ham, a fellow PhD student, just wrote an interface to convert between 
our description and OSPF-TE. This was done in collaboration with Max 
Gigapop, a research network that also developed DRAGON, a free GMPLS 
implementation [6]).

Our work is developed and in limited use in a community of national
research networks called the GLIF [7], which provides circuit-switched
network connection for e-science applications around the globe.
("limited" since it is restricted to a single layer for now).

As for the relation with GMPLS: our model is based on functional
elements as described in ITU-T G.805 [8], combined with the label
concept in GMPLS. That is generic and powerful enough to describe and
find paths in WDM, TDM, Ethernet and fiber switch networks [9].

So much for our model and the shameless plug.
The reason I mention all this is that we are of course not the only ones 
to create a syntax to describe networks. OSPF-TE is an obvious other 
one. There are quite a few research projects which also create their own 
syntax. Some use GMPLS, though most that involve multi-layer networks 
create their own model and syntax. About a year ago, some of these 
groups joined forces to standardize on a network description.

The Open Grid Forum (OGF) [1], a standardization body originally active 
in standardization of Grid software, has a working group, called Network 
Markup Language (NML), which does exactly such multi-layer network 
modelling [10]. Active members are us, developers of the PerfSONAR 
measurement software, and miscellaneous partners in GÉANT (European 
research network) projects. Each of these active members brings their 
own multi-layer models, each with each strengths and weaknesses.

Clearly there is some overlap with CCAMP here. Of course, there are 
difference as well. The NML working groups mostly is concerned with 
multi-domain descriptions, and the interactions needed there. Thus, the 
ability to describe an abstracted view of the network, with capability 
information, pointers to services for policy decision and policy 
enforcement points, etc. Typical projects I see are research projects 
that provide dedicated network connections (either using Ethernet, DWDM, 
or TDM) through a collaboration of 5-20 network domains, each using 
their own inter-domain control plane software. Typical control planes I 
see are DRAGON, UCLP, G-Lambda, DRAC, AutoBAHN, etc.

If you are interested, I gladly elaborate on either our model, the path
finding, or the working group.

Perhaps it would be could that we can share some of our use cases, 
requirements and solutions, while you some of the active members here 
could provide the NML working group with input from the CCAMP group.

With kind regards,
Freek Dijkstra

[1] OGF  http://www.ogf.org/
[2] Network Description Language,
http://www.science.uva.nl/research/sne/ndl/
[3] Loop example in multi layer networks
http://staff.science.uva.nl/~fdijkstr/presentations/Going-in-Loops.pdf
(poster) or
http://staff.science.uva.nl/~fdijkstr/publications/ndl-pathfinding.pdf
(short article)
[4] Semantic web, http://www.w3.org/2001/sw/
[5] 4k digital cinema, http://www.cinegrid.org/
[6] DRAGON, http://dragon.maxgigapop.net/
[7] GLIF community, http://www.glif.is/
[8] ITU-T G.805, http://www.itu.int/rec/T-REC-G.805/
[9] Technology descriptions in NDL,
http://www.science.uva.nl/research/sne/ndl/?c=01-Schemas
[10] NML-WG, https://forge.gridforum.org/sf/projects/nml-wg
https://forge.gridforum.org/sf/projects/nml-wg

Re: Poll for WG Adoption of Two WSON documents

Thanks for the good comments Giovanni, we'll incorporate them into the 
next revision. Also see below.

Greg B.

Giovanni Martinelli wrote:
> Hi,
>
> yes support both
>
> I have also few comments on Framework WSON
>
> -  Section 3.3.1
> How about using a more generic OXC model? Or may be having a two 
> pictures, one with the current ROADM and one with an OXC (degree > 
> 2)?  For sure the simple ROADM it's the easier to understand but looks 
> to me too specific.
--> We've (authors of the WSON info model draft) have been discussing 
these issues lately. So we'll be sure to make this more generic in at 
least one of the drafts (if not both).
>
>
> The text: "As the degree of the ROADM increases beyond two it can have 
> properties of both a switch(OXC)and a multiplexer"
> To me looks like the figure 1 has already multiplexing capability 
> correct? For example a wavelength entering in what you call an add 
> port is multiplexed on a *line* (keeping same terminology of the 
> document) port.
>
> A simple questions on the switching matrix: looks like add/drop ports 
> and *line* ports are considered the same in the matrix, correct?
--> Yes. The difference between port types is given by the per port 
wavelength constraints.  We are currently trying to make this a bit more 
rigorous.
>
> - Section 4.1
> About time frame classification: Dynamic, pseudo-static and static. 
> While the text explains why an RWA would appreciate some temporal 
> information a classification like  "relatively short" or "moderately 
> long"  are a bit difficult to understand to me, Long or short are 
> compared to what?.
--> We'll fix this and/or remove it. Others share you concerns including 
the WG chairs.
>
> - Section 6 Security
> Does it worth a reference to 
> http://tools.ietf.org/id/draft-fang-mpls-gmpls-security-framework-01.txt?
--> Yes.
>
> - A small ed note: in reference section the [G.994.1] is within both 
> normative and informative sub-sections...
--> All my fault.  Will Fix.
>
> Cheers
> G
>
>
>
>
>
>
> BRUNGARD, DEBORAH A, ATTLABS wrote:
>> CCAMP,
>>  
>> From Philadelphia, we had good support for adoption of two of the 
>> WSON documents as CCAMP working group documents:
>>  
>> - Framework for WSON
>> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt 
>>
>>  
>> - Lambda Labels
>> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt 
>>
>>  
>> Please express your opinions (authors, we welcome your opinion also).
>>  
>> Thanks,
>> Adrian and Deborah
>
>

--

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Re: Network modeling & NML group in the OGF

I got some off-list replies. Let me elaborate a bit.

The network markup language (NML) working group in the OGF -in my view- 
seems focussed on network descriptions for multi-domain scenarios. In 
those scenarios loose coupling and extensions to refer to other 
resources are important. GMPLS seems mostly focussed on a control plane 
within a single administrative domain.

Nevertheless, I see overlap. I imagine a future where GMPLS is used 
within a single administrative domain, that data is extracted and in 
abstracted form announced to select partners for multi-domain lightpath 
provisioning.

Such a tool would be a lot easier if there was a common network model. 
Translating between two syntaxes is easy. Translating between two models 
is very hard.

In an ideal world, every technology uses the same model, so conversion 
is easy. We don't live in an ideal world. For example, GMPLS does NOT 
follow G.805 and G.8080. To give two examples: Fundamental concepts in 
GMPLS are labels and capacity (bandwidth). Neither of these concept is 
is present in G.805. In GMPLS, there is no 1:1 relation between 
encapsulation "layers" and switching capability "layers". In GMPLS, 
there is (link connections and subnetwork connections are on the same 
layer network).

Because of this difference in model, it is hard to convert from a set of 
TLV in OSPF-TE and a network description in G.805 functional elements or 
vice versa.

What I would hope for the NML working group is to learn as much as 
possible from all these different models, and decide on one which is 
most usable for all, and is easy to convert to other models and syntaxes.

Clearly, G.805 and G.8080 are input, but they are not complete (*). The 
model (if any) used in GMPLS is another input, and I am seeking that 
input from this list.

Regards,
Freek

(*) For example, we like to add time-based information to track changes 
in the network topology. We like the label and switching capability 
concepts in GMPLs, neither of which is in G.805 or G.8080. Also you 
don't want to know how many people assume that a device interface maps 
to a single G.805 "connection point" -- that is not true, since a device 
interface is a physical interface, which may map to multiple logical 
interfaces, one for each layer. These things need to be specified.

PS: It was perhaps not completely clear in my previous mail. We (the 
developers of the network description language, NDL) use RDF. However 
that this is not always true for everyone in the Network markup language 
(NML) working group in the OGF. Most of the other partners prefer to use 
XML for example. We decided to simply come up with a common model in 
UML, and allow multiple syntaxes. Again, if there is a common model, 
translating between syntaxes is trivial. That common model is the hard part.

Re: Poll for WG Adoption of Two WSON documents

I support both. Those are important docs. Sorry for being late.

Kohei

> CCAMP,
>  
> From Philadelphia, we had good support for adoption of two of the WSON 
> documents as CCAMP working group documents:
>  
> - Framework for WSON
> http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt
>  
> - Lambda Labels
> http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt
>  
> Please express your opinions (authors, we welcome your opinion also).
>  
> Thanks,
> Adrian and Deborah
--

-- 
Kohei Shiomoto, Ph.D
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402 Fax +81 422 59 3787
Free online contents of "NTT Technical Review" available at
https://www.ntt-review.jp/

proposed charter update for the MPLS TP work

MPLS, CCAMP and PWE3 working groups,

The Joint Working Team of the IETF and ITU-T has resulted in
the agreement to create a Transport Profile for MPLS (MPLS TP).
This effort requires the MPLS, PWE3 and CCAMP Working Groups
are chartered to do the required work.

The MPLS, PWE3 and CCAMP chairs proposes that we add the
following paragraph to the three working group charters:

   "- Include extensions to the [MPLS, PWE3, CCAMP] protocols and RFCs
      necessary to fulfill an MPLS Transport Profile (MPLS TP), the work
      on the MPLS TP needs to be coordinated between the three working
      groups (MPLS, PWE3 and CCAMP) that are chartered to do MPLS TP
      work."

Please send your comments to the working group(s) mailing list(s)
eob Friday May 16.

Adrian, Deborah, Danny, Stewart, George and Loa

--

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson <at> acreo.se
                                            loa <at> pi.nu