Common Control and Measurement Plane (ccamp)

Lou Berger | 21 May 2013 15:16

Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

All,

In the interest of moving this discussion quickly to closure, I spent
some time trying to come up with the full list of G.709 PT to G-PID
mappings.  In coming up with this list I tried to be consistent with
the last consensus point that I can identify on this topic (the
previously referenced July 2012 thread & presentation), which included:

A) Defining new G-PIDs for client types not identified by an assigned
G-PID (per
http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml)

B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a
G.709 payload type, and define new G-PIDs when reuse not possible.

C) No G-PID value for unused, reserved, or proprietary 709 Payload Type.

Here's what I've come up with:

    G.709
   Payload
    Type   G-PID   Type/Comment    LSP Encoding
    ====   =====   ==============  ===================
    0x01           No standard value
    0x02    49     CBRa            G.709 ODUk
    0x03    50     CBRb            G.709 ODUk
    0x04    32     ATM             G.709 ODUk
    0x05    TBA1   Framed GFP      G.709 ODUk
    0x06    ???    Is any valued needed?
    0x07    55     Ethernet PHY    G.709 ODUk (k=0)

(Continue reading)

headers

Leeyoung | 13 May 2013 20:55

FW: I-D Action: draft-ietf-ccamp-rwa-info-18.txt

Hi,

This update (v.18) revived the expired draft with the added clarification texts thanks to Lou.

The major changes are as follows:

1. <ClientSignalList> is added in <OutputConstraints> in Section 5.2 as
   follows:  <OutputConstraints> := <SharedOutput>
   [<OpticalInterfaceClassList>][<ClientSignalList>]

2. Clarified the scope of Section 6 (Link Advertisement) that these
   additional link characteristics defined in Section 6 only applies to
   line side ports of WDM system or add/drop ports pertaining to
   Resource Pool (e.g., Regenerator or Wavelength Converter Pool) and
   not intended for ingress/egress tributary ports.

Let me know if you have any question on this change or any comment on the updated draft. 

Regards,
Young

-----Original Message-----
From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org] On Behalf Of internet-drafts <at> ietf.org
Sent: Monday, May 13, 2013 1:49 PM
To: i-d-announce <at> ietf.org
Cc: ccamp <at> ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-18.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.

(Continue reading)

headers

internet-drafts | 13 May 2013 20:48

I-D Action: draft-ietf-ccamp-rwa-info-18.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           : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-rwa-info-18.txt
	Pages           : 28
	Date            : 2013-05-13

Abstract:
   This document provides a model of information needed by the routing
   and wavelength assignment (RWA) process in wavelength switched
   optical networks (WSONs).  The purpose of the information described
   in this model is to facilitate constrained lightpath computation in
   WSONs. This model takes into account compatibility constraints
   between WSON signal attributes and network elements but does not
   include constraints due to optical impairments. Aspects of this
   information that may be of use to other technologies utilizing a
   GMPLS control plane are discussed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18

(Continue reading)

headers

Daniele Ceccarelli | 13 May 2013 10:03

Re: [CCAMP WG] #50: Identification of hexadecimal representation in G.709 vs decimal in GMPLS

Lou, CCAMP,

This is the proposed text for the info-model wrt the decimal vs hexadecimal encoding issue.

13.  Identification of hexadecimal representation in G.709 vs decimal in
     GMPLS considerations

   Encoding in GMPLS foresses the utilization of hexadecimal values
   format "0x" while in the data plane documents, like G.709
   reccomendation, the format usually used is the decimal one (e.g.
   G-PID in RSVP-TE vs Payload Type in G.709). 

BR
Daniele & Sergio

>-----Original Message-----
>From: ccamp issue tracker [mailto:trac+ccamp <at> trac.tools.ietf.org] 
>Sent: mercoledì 8 maggio 2013 19.22
>To: draft-ietf-ccamp-otn-g709-info-model <at> tools.ietf.org; 
>lberger <at> labn.net
>Cc: ccamp-chairs <at> tools.ietf.org
>Subject: [CCAMP WG] #50: Identification of hexadecimal 
>representation in G.709 vs decimal in GMPLS
>
>#50: Identification of hexadecimal representation in G.709 vs 
>decimal in GMPLS
>
> From: http://www.ietf.org/mail-archive/web/ccamp/current/msg14812.html
>
>   The authors had previously stated the intent to just make this clear

(Continue reading)

headers

Lou Berger | 8 May 2013 18:52

Closing G.709 open issues

Authors/WG,
	I think all would like to wrap up the 709 documents before
Berlin.  To do this we need to:
1) Ensure all discussed points have been resolved
2) Hold a 2nd LC to ensure consensus on all changes since the 1st LC
3) Capture the resolution of any comments made during 2.

In reviewing the close to 200 mail messages on the documents since the
1st LC was issued, I see only one a few points that are still missing,
and I'll cover these below.  On a side note, as an experiment we'll be
tracking these issue via the tools issues page:
http://tools.ietf.org/wg/ccamp/trac/report/1

PLEASE reply to this message if you think there are other
points/discussions that haven't been addressed in the current set of
documents. Once this thread is closed, the 2nd LC will be initiated.

The remaining items come from the tread with the final message
http://www.ietf.org/mail-archive/web/ccamp/current/msg14701.html
The message is from me in response to Daniele's summary of next steps,
and has the following unresolved actions:

1)  No explicit indication of TSG in the label [SIGNALING]

  In signaling document section 6: Clarify related text to unambiguous
  identify the relationship between label length and TSG. Possible
  target text to change:
   Note that the
   Length field in the label format MAY be used to indicate the TS
   type of the HO ODUk (i.e., TS granularity at 1.25Gbps or 2.5Gbps)

(Continue reading)

headers

internet-drafts | 6 May 2013 23:59

I-D Action: draft-ietf-ccamp-general-constraint-encode-11.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           : General Network Element Constraint Encoding for GMPLS Controlled Networks
	Author(s)       : Greg M. Bernstein
                          Young Lee
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-general-constraint-encode-11.txt
	Pages           : 31
	Date            : 2013-05-06

Abstract:
   Generalized Multiprotocol Label Switching can be used to control a
   wide variety of technologies. In some of these technologies network
   elements and links may impose additional routing constraints such as
   asymmetric switch connectivity, non-local label assignment, and
   label range limitations on links.

   This document provides efficient, protocol-agnostic encodings for
   general information elements representing connectivity and label
   constraints as well as label availability. It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode

There's also a htmlized version available at:

(Continue reading)

headers

johnsonhammond2 | 27 Apr 2013 19:12

Biggest Fake Conference in Computer Science

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See

(Continue reading)

headers

BRUNGARD, DEBORAH A | 26 Apr 2013 19:34

WG Last Call on draft-ietf-ccamp-swcaps-update-01.txt

All,

This starts a two-week working group last call on draft-ietf-ccamp-swcaps-update-01.txt.

This working group last call ends May 10th, 2013.

Please send your comments to the CCAMP mailing list.

Deborah (and Lou)

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

headers

Annapoorni Neelankantan | 22 Apr 2013 14:49

questions regarding [gen-encode] draft

Hello Authors,

I have few questions regarding the [gen-encode draft] - “draft-ietf-ccamp-general-constraint-encode-10.txt

The mentioned draft has expired on 28 march 2013. But all the WSON specific documents refer to this document for reference.

Is the “draft-ietf-ccamp-general-constraint-encode-10.txt still valid??

Questions pertaining to “draft-ietf-ccamp-general-constraint-encode-10.txt”

1) In Section 2.3.Available Labels Sub-TLV defines priority as 8 bits.

However in the example

A.5. Priority Flags in Available/Shared Backup Labels sub-TLV

Priority is defined as 3 bits.

Since there is a mismatch, How many bits should be used to represent priority?

2) In the same example A.5 Priority Flags in Available/Shared Backup Labels sub-TLV,

7 mentioned as the highest priority. In ASON/Packet world, “0” is the highest priority and “7” the lowest.

Could you please comment as to whether 0 or 7 constitutes highest priority ?

3) In section 2.3. Available Labels Sub-TLV

The Available Labels sub-TLV link consists of an availability flag,

priority flags, and a single variable length label set field as

follows:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| PRI | Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Label Set Field |

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where

PRI (Priority Flags, 8 bits): Indicates priority level applied to

Label Set Field. Bit 8 corresponds to priority level 0 and bit 15

corresponds to priority level 7.

a) What is the use/definition of availability flag ?

b) Where should priority be encoded, in the first byte(0-7bits) or (8-15bits)? Diagram show the first byte whereas the

explanation says it as the second byte.

4) In “Available Labels Sub-TLV”, assuming Priority is defined by 8 Bits –

If two bits are set to indicate that available labels for 2 priorities, should the available labels at each priority be encoded as below?

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 01000001 | Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Label Set Field for priority = 1 |

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Label Set Field for priority = 7 |

: :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5) In the “Label Set” field of Available Label set TLV, what does “Lowest Frequency” signify?

Is it the lowest frequency supported by the port for a particular grid and channel spacing ?

OR

Is it the lowest available frequency i.e the lowest frequency which is not in use, at that point in time?

In Example A.2 in the draft,

For the following frequencies which are available (and not in use)

Frequency (THz) n Value bit map position

--------------------------------------------------

192.0 -11 0

192.5 -6 5

193.1 0 11

193.9 8 19

194.0 9 20

195.2 21 32

195.8 27 38

Encoding is:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 4 | Num Wavelengths = 40 | Length = 16 bytes |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If the available frequencies are:

Frequency (THz) n Value bit map position

--------------------------------------------------

193.9 8 19

194.0 9 20

195.2 21 32

195.8 27 38

Will the value of “n” change in the encoding change to “8”, OR will it still remain “-11” ?

Will the Encoding change as below:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 4 | Num Wavelengths = 40 | Length = 16 bytes |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|1 0 0 0 0 0 1 0| Not used in 40 Channel system (all zeros) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks

Annapoorni

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

headers

BRUNGARD, DEBORAH A | 18 Apr 2013 18:30

Regarding IPR on draft-ietf-ccamp-swcaps-update

Authors, Contributors, (CCAMP)

In preparation of this document for Last Call:

Are you aware of any IPR that applies to draft-ietf-ccamp-swcaps-update?

If so, has this IPR been disclosed in compliance with IETF IPR

rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor, please answer the above

by responding to this email regardless of whether or not you are aware of any

relevant IPR. This document will not advance to the next stage until a response

has been received from each author and listed contributor.

If you are on the CCAMP WG email list but are not listed as an author or

contributor, we remind you of your obligations under the IETF IPR rules which

encourages you to notify the IETF if you are aware of IPR of others on an IETF

contribution, or to refrain from participating in any contribution or discussion

related to your undisclosed IPR. For more information, please see the RFCs listed

above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,

CCAMP WG Chairs

PS Please include all listed in the headers of this message in your response.

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

headers

Iftekhar Hussain | 13 Apr 2013 21:27

FW: New Version Notification for draft-hussain-ccamp-super-channel-label-05.txt

Hi,

Just FYI...

Regards,
Iftekhar
-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Saturday, April 13, 2013 10:13 AM
To: Iftekhar Hussain
Cc: Marco Sosa; abinder.dhillon <at> us.fujitsu.com; Zhong Pan; andrew.g.malis <at> verizon.com
Subject: New Version Notification for draft-hussain-ccamp-super-channel-label-05.txt

A new version of I-D, draft-hussain-ccamp-super-channel-label-05.txt
has been successfully submitted by Iftekhar Hussain and posted to the IETF repository.

Filename:	 draft-hussain-ccamp-super-channel-label
Revision:	 05
Title:		 Generalized Label for Super-Channel Assignment on Flexible Grid
Creation date:	 2013-04-13
Group:		 Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-hussain-ccamp-super-channel-label-05.txt
Status:          http://datatracker.ietf.org/doc/draft-hussain-ccamp-super-channel-label
Htmlized:        http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-hussain-ccamp-super-channel-label-05

Abstract:
   To enable scaling of existing transport systems to ultra high data
   rates of 1 Tbps and beyond, next generation systems providing super-
   channel switching capability are currently being developed. To allow
   efficient allocation of optical spectral bandwidth for such high bit
   rate systems, International Telecommunication Union
   Telecommunication Standardization Sector (ITU-T) is extending the
   G.694.1 grid standard (termed "Fixed-Grid") to include flexible grid
   (termed "Flex-Grid") support (draft revised ITU-T G.694.1, revision
   1.4, Oct 2011). This necessitates definition of new label format for
   the Flex-Grid. This document defines a super-channel label as a
   Super-Channel Identifier and an associated list of 12.5 GHz slices
   representing the optical spectrum of the super-channel. The label
   information can be encoded using a fixed length or variable length
   format. This label format can be used in GMPLS signaling and routing
   protocol to establish super-channel based optical label switched
   paths (LSPs).

The IETF Secretariat

_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

60	May 2013
74	April 2013
120	March 2013
94	February 2013
197	January 2013
150	December 2012
46	November 2012
129	October 2012
128	September 2012
203	August 2012
95	July 2012
62	June 2012
103	May 2012
60	April 2012
152	March 2012
77	February 2012
33	January 2012
66	December 2011
87	November 2011
121	October 2011
104	September 2011
43	August 2011
271	July 2011
87	June 2011
37	May 2011
204	April 2011
82	March 2011
29	February 2011
33	January 2011
27	December 2010
91	November 2010
81	October 2010
41	September 2010
27	August 2010
200	July 2010
44	June 2010
38	May 2010
106	April 2010
94	March 2010
64	February 2010
27	January 2010
85	December 2009
82	November 2009
96	October 2009
75	September 2009
50	August 2009
55	July 2009
60	June 2009
35	May 2009
39	April 2009
88	March 2009
53	February 2009
42	January 2009
98	December 2008
69	November 2008
113	October 2008
50	September 2008
85	August 2008
72	July 2008
16	June 2008
40	May 2008
101	April 2008
95	March 2008
38	February 2008
75	January 2008
61	December 2007
47	November 2007
98	October 2007
88	September 2007
69	August 2007
78	July 2007
36	June 2007
29	May 2007
80	April 2007
131	March 2007
48	February 2007
58	January 2007
51	December 2006
48	November 2006
46	October 2006
71	September 2006
133	August 2006
202	July 2006
118	June 2006
76	May 2006
88	April 2006
68	March 2006
32	February 2006
30	January 2006
67	December 2005
86	November 2005
170	October 2005
75	September 2005
122	August 2005
225	July 2005
82	June 2005
41	May 2005
102	April 2005
151	March 2005
118	February 2005
66	January 2005
82	December 2004
126	November 2004
74	October 2004
48	September 2004
66	August 2004
102	July 2004
38	June 2004
74	May 2004
167	April 2004
285	March 2004
55	February 2004
77	January 2004
59	December 2003
222	November 2003
81	October 2003
64	September 2003
30	August 2003
67	July 2003
74	June 2003
191	May 2003
85	April 2003
213	March 2003
89	February 2003
58	January 2003
148	December 2002
68	November 2002
24	October 2002
94	September 2002
103	August 2002
42	July 2002
76	June 2002
151	May 2002
150	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31