Subject: [CCAMP] rwa wson framework: multi-degree ROADM

From: Giovanni Martinelli <[email-masked]>
Date: Tue, 15 Sep 2009 17:26:08 +0200

Hi Greg & WSONers,

well, I saw you just suggest a last call request but I was wondering 
about representing a more general case of ROAM in section 3.3.1

The ID currently represent a 2 degree ROADM but looks to me a very 
specific case so I'm asking if it's ok adding a 4 degree ROADM as well.

Here just a rough idea starting from your current picture

                         +---------------------+  
Line side-1 ingress  --->|                     |--->  Line side-2 egress
Line side-1 egress   <---|                     |<---  Line side-2 ingress
                         |        ROADM        |
Line side-3 ingress  --->|                     |--->  Line side-4 egress
Line side-3 egress   <---|                     |<---  Line side-4 ingress
                         |                     |
                         +---------------------+
                            | | | |  o o o o
                            | | | |  | | | |
                            O O O O  | | | |
      Tributary Side:   Drop (egress)  Add (ingress)

1/ line sides likely have ingress and egress.

2/ Tributaries might be associated to sides but I would consider that 
as  switching constrain.

Does the switching matrix will apply in the same way, become an 8x8 right?.

Any thoughts about?

Cheers
G

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 15 Sep 2009 08:47:11 -0700

Hi Giovanni, in the example given in section 5 (thanks to Dirk) we have 
multi-degree ROADMs. In section 3.3.1 we do mention higher degree ROADMs 
but refer readers to another draft. Hmm, maybe we should also point them 
to section 5. While I don't mind adding another picture, I think the 
chairs will be more interested in us reducing the length of the document 
than expanding it ;-) .

Cheers

Greg

Giovanni Martinelli wrote:
>                         +---------------------+  Line side-1 ingress  
> --->|                     |--->  Line side-2 egress
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

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

---

From: Giovanni Martinelli <[email-masked]>
Date: Thu, 17 Sep 2009 09:59:04 +0200

Hi Greg,

Greg Bernstein wrote:
> Hi Giovanni, in the example given in section 5 (thanks to Dirk) we 
> have multi-degree ROADMs. In section 3.3.1 we do mention higher degree 
> ROADMs but refer readers to another draft. Hmm, maybe we should also 
> point them to section 5. 

um well Section 5 provide more a high level overview and the scope is a 
bit different while the other reference at the end still contain 2 
degree roadm (unless I'm missing something)

This section was providing details about how a roadm is presented and 
the respective connectivity matrix (while in other examples the 
connectivity matrix only shows what is important for the example itself).

To me this is important to show how exactly every roadm can be 
represented (and I guess generalizing from 4 to n will be clearer than 
doing from 2 to n degree) and the size of  the matrix (then how is 
sparse is another topic).

> While I don't mind adding another picture, I think the chairs will be 
> more interested in us reducing the length of the document than 
> expanding it ;-) .
>
well hope it's not the main criteria (we can always shot for the longest 
RFC) ;-)

Cheers
G

---

From: Young Lee <[email-masked]>
Date: Fri, 18 Sep 2009 14:56:31 -0500

Hi Giovanni, 

We have added 4-degree ROADM figure and connectivity matrix per your
suggestion in the draft. Below is tentative text we have added in Section
3.3.1. I hope this would satisfy your request. 

Thanks. 

Young
----------------------------------------------------------------

Ingress 1  +---------------+    +---------------+    Egress 1           
     ----> |               | -->|               |----> 
Ingress 2  |               |    |               |    Egress 2
     ----> |               | -->|		      |----> 
           +---------------+    +---------------+
             | | |    | | |      O O O     O O O
             | | |    | | |      | | |     | | |
             O O O    O O O      | | |     | | |
          	E3 E4 E5  E6 E7 E8   I3 I4 I5  I6 I7 I8
               
Triburary Side     Drop                 Add 

Figure 2	Degree-4 ROADM

For the ROADM of Figure 2 the switched connectivity matrix can be expressed
as follows. Note that this ROADM is based on per port add/drop. 

	Ingress	Egress Port
	Port		#1 #2	#3 #4	#5 #6 #7 #8
			--------------
		#1:	1  1 	0  0  0  1 	1  1
		#2	1  1  1  1  1  0 	0  0
   	A =	#3	0  1 	0  0 	0  0  0  0
		#4	0  1 	0  0 	0  0	0  0
		#5	0  1 	0  0 	0  0  0  0
            #6    1  0  0  0  0  0  0  0 
            #7   	1  0  0  0  0  0  0  0 
            #8    1  0  0  0  0  0  0  0

Where egress ports 3-5 are drop ports from Ingress 2 and egress ports 6-8
are drop ports from Ingress 1 and ingress ports 3-5 are add ports to Egress
2, ingress ports 6-8 are add ports to Egress 1.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Giovanni Martinelli
Sent: Thursday, September 17, 2009 2:59 AM
To: Greg Bernstein
Cc: [email-masked]
Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM

Hi Greg,

Cheers
G

---

From: Jonas Mårtensson <[email-masked]>
Date: Mon, 21 Sep 2009 17:21:11 +0200

Hi Young,

Actually, I think the figure you propose is a bit confusing for a couple of reasons:

1) It only depicts either ingress or egress for the four directions while in practice links are typically bidirectional. (The same is true for the degree-2 ROADM example in the draft but there it is less confusing.)

2) The way the ports are numbered, to me it looks like Ingress 1(2) and Egress 1(2) are associated to the same direction which means that to me it looks more like a degree-2 ROADM.

I think it would be clearer if you made all ports in the figures bidirectional.

Regards,
Jonas

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Young Lee
> Sent: den 18 september 2009 21:57
> To: 'Giovanni Martinelli'
> Cc: [email-masked]
> We have added 4-degree ROADM figure and connectivity matrix 
> per your suggestion in the draft. Below is tentative text we 
> have added in Section 3.3.1. I hope this would satisfy your request. 
> 
> Thanks. 
> 
> Young
> For the ROADM of Figure 2 the switched connectivity matrix 
> can be expressed as follows. Note that this ROADM is based on 
> per port add/drop. 
> 
> 	Ingress	Egress Port
> Where egress ports 3-5 are drop ports from Ingress 2 and 
> egress ports 6-8 are drop ports from Ingress 1 and ingress 
> ports 3-5 are add ports to Egress 2, ingress ports 6-8 are 
> add ports to Egress 1.
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Giovanni Martinelli
> um well Section 5 provide more a high level overview and the 
> scope is a bit different while the other reference at the end 
> still contain 2 degree roadm (unless I'm missing something)
> 
> This section was providing details about how a roadm is 
> presented and the respective connectivity matrix (while in 
> other examples the connectivity matrix only shows what is 
> important for the example itself).
> 
> To me this is important to show how exactly every roadm can 
> be represented (and I guess generalizing from 4 to n will be 
> clearer than doing from 2 to n degree) and the size of  the 
> matrix (then how is sparse is another topic).
> 
> 
> >> Does the switching matrix will apply in the same way, 
> become an 8x8 
> >> right?.
> >>
> >> Any thoughts about?
> >>
> >>
> >> Cheers
> >> G

---

From: Young Lee <[email-masked]>
Date: Mon, 21 Sep 2009 10:57:00 -0500

Hi Jonas,

Yes you are right. Due to the ASCII limitation, the figures for both
2-degree and 4-degree ROADM are shown only for one direction. For your
question (2), we have added a note that this ROADM is based on per port
add/drop (which is hard to show with ASCII) which means Ingress 1(2) and
Egress 1(2) are associated to the different directions. 

Hope this clarifies your question... Thanks. 

Regards,
Young

-----Original Message-----
From: Jonas Mårtensson [mailto:[email-masked]] 
Sent: Monday, September 21, 2009 10:21 AM
To: Young Lee; 'Giovanni Martinelli'
Cc: [email-masked]
Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM

Hi Young,

Actually, I think the figure you propose is a bit confusing for a couple of
reasons:

1) It only depicts either ingress or egress for the four directions while in
practice links are typically bidirectional. (The same is true for the
degree-2 ROADM example in the draft but there it is less confusing.)

2) The way the ports are numbered, to me it looks like Ingress 1(2) and
Egress 1(2) are associated to the same direction which means that to me it
looks more like a degree-2 ROADM.

I think it would be clearer if you made all ports in the figures
bidirectional.

Regards,
Jonas

---

From: Giovanni Martinelli <[email-masked]>
Date: Mon, 21 Sep 2009 18:25:57 +0200

Hi,

Young Lee wrote:
> 2-degree and 4-degree ROADM are shown only for one direction. 
although ascii art difficult, I got the issue in understanding where 
bi-directionality apply as well. That's why I was trying to get all 
directions in one picture (but not sure the result was ok).

> For your
One more clarification on the topic: the fact that we represent 
connectivity matrix done by (ingress x egress) it means we have a matrix 
for each directions?

thx
G

>>> have multi-degree ROADMs. In section 3.3.1 we do mention 
>>>       
>> higher degree 
>>     
>>> ROADMs but refer readers to another draft. Hmm, maybe we 
>>>       
>> should also 
>>     
>>> point them to section 5.
>>>       
>>> While I don't mind adding another picture, I think the 
>>>       
>> chairs will be 
>>     
>>>> well, I saw you just suggest a last call request but I was 
>>>>         
>> wondering 
>>     
>>>> specific case so I'm asking if it's ok adding a 4 degree 
>>>>         
>> ROADM as well.
>>     
>>>>                         +---------------------+  Line 
>>>>         
>> side-1 ingress
>>     
>>>> Line side-3 ingress  --->|                     |--->  Line 
>>>>         
>> side-4 egress
>>     
>>>> 2/ Tributaries might be associated to sides but I would 
>>>>         
>> consider that 
>>     
>>>> as  switching constrain.
>>>>

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 21 Sep 2009 11:12:07 -0700

Hi folks, for the framework document we currently have an example of a 
2-Degree unidirectional ROADM. Which represents about the simplest 
asymmetric switching  system we can show.  The  general connectivity 
matrix  formulation is at its core is unidirectional, i.e.,  deals with 
the potential connectivity of each ingress and egress pair separately to 
be generally applicable. Note that the encoding draft hits the issue of 
how to represent this stuff compactly on the wire.

Note the size of the  matrix is in terms of (# of ingress ports) X  (# 
of egress ports) and don't forget to include add and drop ports. The 
interesting feature of higher degree ROADMs is that two ROADMs of the 
same "degree"  may have very different connectivity properties. For 
example in architectures based on add/drop per node versus add/drop per 
fiber. In your 4-degree example Giovanni the number of add and drop 
ports seemed rather small and seems to make it hard to illustrate the 
difference between a "drop per node" and a "drop per fiber" style 
architecture.

What aspects do you want to see illustrated most in this section of the 
draft? I'm thinking of adding some  text to address the general case a 
bit more since the draft can refer to a published paper (in JOCN) that 
furnishes a significant number of examples of higher order and 
bidirectional ROADMs.

Cheers

Greg

Giovanni Martinelli wrote:
> connectivity matrix done by (ingress x egress) it means we have a 
> matrix for each directions?
>
> thx
> G
>
>> From: Jonas Mårtensson [mailto:[email-masked]] Sent: 
>> Monday, September 21, 2009 10:21 AM
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Young Lee
>>> suggestion in the draft. Below is tentative text we have added in 
>>> Section 3.3.1. I hope this would satisfy your request.
>>> Thanks.
>>> Young
>>> For the ROADM of Figure 2 the switched connectivity matrix can be 
>>> expressed as follows. Note that this ROADM is based on per port 
>>> add/drop.
>>>     Ingress    Egress Port
>>>             #6    1  0  0  0  0  0  0  0             #7       1  0  
>>> 0  0  0  0  0  0             #8    1  0  0  0  0  0  0  0
>>>   
>>> Where egress ports 3-5 are drop ports from Ingress 2 and egress 
>>> ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are 
>>> add ports to Egress 2, ingress ports 6-8 are add ports to Egress 1.
>>>
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Giovanni Martinelli
>>> um well Section 5 provide more a high level overview and the scope 
>>> is a bit different while the other reference at the end still 
>>> contain 2 degree roadm (unless I'm missing something)
>>>
>>> This section was providing details about how a roadm is presented 
>>> and the respective connectivity matrix (while in other examples the 
>>> represented (and I guess generalizing from 4 to n will be clearer 
>>> than doing from 2 to n degree) and the size of  the matrix (then how 
>>> is sparse is another topic).
>>>
>>>
>>>

---

From: Jonas Mårtensson <[email-masked]>
Date: Tue, 22 Sep 2009 10:22:17 +0200

Hi,

Greg, as you say, the encoding draft specifies an efficient way to represent the connectivity of a switching node. However, the current (uni-directional) examples in section 3.1.1 of the framework draft do not illustrate one reason why the encoding draft representation is efficient, which is that the connectivity constraints for typical ROADM designs are "bi-directional", i.e. if ingress port X can (or can't) be connected to egress port Y, typically ingress port Y can (or can't) be connected to egress port X, assuming the numbering is done in such a way that ingress X and egress X correspond to the same line side direction or the same add/drop port. This makes the connectivity matrix symmetrical (which can be taken advantage of by setting the directionality bits of the link sets in the encoding draft representation to bidirectional). Borrowing Giovanni's (slightly modified) proposed 4-degree example with one (potentially multi-channel) add/drop per line side port to illustrate : 

                             +------------------------+  
Line side-1 ingress (I1) --->|                        |--->  Line side-2 egress (E2)
Line side-1 egress (E1)  <---|                        |<---  Line side-2 ingress (I2)
                             |        ROADM           |
Line side-3 ingress (I3) --->|                        |--->  Line side-4 egress (E4)
Line side-3 egress (E3)  <---|                        |<---  Line side-4 ingress (I4)
                             |                        |
                             +------------------------+
                              | O    | O    | O    | O
                              | |    | |    | |    | |
                              O |    O |    O |    O |
         Tributary Side:     E5 I5  E6 I6  E7 I7  E8 I8

Corresponding 8x8 sparse and symmetrical connectivity matrix:

	Ingress	Egress Port
	Port		E1 E2	E3 E4	E5 E6 E7 E8
			--------------
		I1	0  1 	1  1  0  1 	0  0
		I2	1  0  1  1  0  0 	1  0
   	A =	I3	1  1 	0  1 	1  0  0  0
		I4	1  1 	1  0 	0  0	0  1
		I5	0  0 	1  0 	0  0  0  0
            I6    1  0  0  0  0  0  0  0 
            I7   	0  1  0  0  0  0  0  0 
            I8    0  0  0  1  0  0  0  0

where I5/E5 are add/drop ports to/from line side-3, I6/E6 are add/drop ports to/from line side-1, I7/E7 are add/drop ports to/from line side-2 and I8/E8 are add/drop ports to/from line side-4. Note that diagonal elements are zero since I assume that loopback is not supported. If ports support loopback, diagonal elements would be one.

Do you think such an example would be useful?

Regards,
Jonas

> From: Greg Bernstein [mailto:[email-masked]] 
> Sent: den 21 september 2009 20:12
> To: Giovanni Martinelli
> Cc: Young Lee; [email-masked]; Jonas Mårtensson
> Hi folks, for the framework document we currently have an 
> example of a 2-Degree unidirectional ROADM. Which represents 
> about the simplest asymmetric switching  system we can show.  
> The  general connectivity matrix  formulation is at its core 
> is unidirectional, i.e.,  deals with the potential 
> connectivity of each ingress and egress pair separately to be 
> generally applicable. Note that the encoding draft hits the 
> issue of how to represent this stuff compactly on the wire.
> 
> Note the size of the  matrix is in terms of (# of ingress 
> ports) X  (# of egress ports) and don't forget to include add 
> and drop ports. The interesting feature of higher degree 
> ROADMs is that two ROADMs of the same "degree"  may have very 
> different connectivity properties. For example in 
> architectures based on add/drop per node versus add/drop per 
> fiber. In your 4-degree example Giovanni the number of add 
> and drop ports seemed rather small and seems to make it hard 
> to illustrate the difference between a "drop per node" and a 
> "drop per fiber" style architecture.
> 
> What aspects do you want to see illustrated most in this 
> section of the draft? I'm thinking of adding some  text to 
> address the general case a bit more since the draft can refer 
> to a published paper (in JOCN) that furnishes a significant 
> number of examples of higher order and bidirectional ROADMs.
> 
> Cheers
> 
> Greg
> 
> >> question (2), we have added a note that this ROADM is based on per 
> >> port add/drop (which is hard to show with ASCII) which 
> means Ingress 
> >> 1(2) and Egress 1(2) are associated to the different directions.
> >>   
> >> 1) It only depicts either ingress or egress for the four 
> directions 
> >> while in practice links are typically bidirectional. (The same is 
> >> true for the
> >> 2) The way the ports are numbered, to me it looks like 
> Ingress 1(2) 
> >> and Egress 1(2) are associated to the same direction which 
> means that 
> >> to me it looks more like a degree-2 ROADM.
> >>
> >>>             #6    1  0  0  0  0  0  0  0             #7   
>     1  0  
> >>>>> Line side-1 egress   <---|                     |<---  
> Line side-2 
> >>>>> ingress
> >>>>>                         |        ROADM        |
> >>>>> Line side-3 egress   <---|                     |<---  
> Line side-4 
> >>>>> ingress
> >>>>>                         |                     |
> >>>>>                         +---------------------+
> >>>>>                            | | | |  o o o o
> >>>>>                            | | | |  | | | |
> >>>>>                            O O O O  | | | |

---

From: Giovanni Martinelli <[email-masked]>
Date: Tue, 22 Sep 2009 16:33:00 +0200

Hi

Greg Bernstein wrote:
> matrix  formulation is at its core is unidirectional, i.e.,  deals 
> with the potential connectivity of each ingress and egress pair 
> separately to be generally applicable. Note that the encoding draft 
> hits the issue of how to represent this stuff compactly on the wire.
>
> example in architectures based on add/drop per node versus add/drop 
> per fiber. In your 4-degree example Giovanni the number of add and 
> drop ports seemed rather small and seems to make it hard to illustrate 
> the difference between a "drop per node" and a "drop per fiber" style 
> architecture.
yes I realized I was not so clear... tributary ports can be in really 
high numbers and even there could be several switching constrains on 
tributary vs lines. 

thx
G

>
> What aspects do you want to see illustrated most in this section of 
> the draft? I'm thinking of adding some  text to address the general 
> case a bit more since the draft can refer to a published paper (in 
> JOCN) that furnishes a significant number of examples of higher order 
> and bidirectional ROADMs.
>
> Cheers
>
> Greg
>
>>>> We have added 4-degree ROADM figure and connectivity matrix per 
>>>> your suggestion in the draft. Below is tentative text we have added 
>>>> in Section 3.3.1. I hope this would satisfy your request.
>>>> Thanks.
>>>> Young
>>>> than doing from 2 to n degree) and the size of  the matrix (then 
>>>> how is sparse is another topic).
>>>>
>>>>
>>>>   
>>>>>> The ID currently represent a 2 degree ROADM but looks to me a 
>>>>>> very specific case so I'm asking if it's ok adding a 4 
>>>>>> degree         
>>>> ROADM as well.
>>>>

---

From: Giovanni Martinelli <[email-masked]>
Date: Tue, 22 Sep 2009 16:39:19 +0200

Jonas Mårtensson wrote:
> Hi,
>
> Greg, as you say, the encoding draft specifies an efficient way to represent the connectivity of a switching node. However, the current (uni-directional) examples in section 3.1.1 of the framework draft do not illustrate one reason why the encoding draft representation is efficient, which is that the connectivity constraints for typical ROADM designs are "bi-directional", i.e. if ingress port X can (or can't) be connected to egress port Y, typically ingress port Y can (or can't) be connected to egress port X, assuming the numbering is done in such a way that ingress X and egress X correspond to the same line side direction or the same add/drop port. This makes the connectivity matrix symmetrical (which can be taken advantage of by setting the directionality bits of the link sets in the encoding draft representation to bidirectional). 
Which means that changing directions we need to transpose the matrix, right?

> Borrowing Giovanni's (slightly modified) proposed 4-degree example with one (potentially multi-channel) add/drop per line side port to illustrate : 
>
>
to me yes I like in this way... don't know if others have different 
opinions.
(not sure if, according to previous mail from Greg, there's the need to 
have few more tributaries but the general picture is ok to me).

thx
G

>>>> Yes you are right. Due to the ASCII limitation, the 
>>>>         
>> figures for both 
>>     
>>> although ascii art difficult, I got the issue in 
>>>       
>> understanding where 
>>     
>>>> degree-2 ROADM example in the draft but there it is less 
>>>>         
>> confusing.)
>>     
>>>>> We have added 4-degree ROADM figure and connectivity 
>>>>>           
>> matrix per your 
>>     
>>>>> add ports to Egress 2, ingress ports 6-8 are add ports to 
>>>>>           
>> Egress 1.
>>     
>>>>>> Hi Giovanni, in the example given in section 5 (thanks 
>>>>>>             
>> to Dirk) we 
>>     
>>>>> um well Section 5 provide more a high level overview and 
>>>>>           
>> the scope 
>>     
>>>>> and the respective connectivity matrix (while in other 
>>>>>           
>> examples the 
>>     
>>>>> than doing from 2 to n degree) and the size of  the 
>>>>>           
>> matrix (then how 
>>     
>>>>>>> well, I saw you just suggest a last call request but I 
>>>>>>>               
>> was         
>>     
>>>>> wondering    
>>>>>           
>>>>>>> The ID currently represent a 2 degree ROADM but looks 
>>>>>>>               
>> to me a very 
>>     
>>>>>>> specific case so I'm asking if it's ok adding a 4 
>>>>>>>               
>> degree         
>>     
>>>>> ROADM as well.
>>>>>    
>>>>>           
>>>>>>> Line side-3 ingress  --->|                     |--->  
>>>>>>>               
>> Line         
>>     
>>>>> side-4 egress
>>>>>    
>>>>>

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 22 Sep 2009 07:51:18 -0700

Thanks Jonas, this example seems good in that it illustrates:
(a) Bi-directional ROADM
(b) Higher degree ROADM
(c) A more complicated connectivity matrix due to the per port type of 
add/drop connectivity.

Although the number of add/drop ports is low we could comment in the 
text that this is for simplicity in drawing the figure.
I was thinking of then adding this example to section 3.3.1 after the 
simple example of the unidirectional 2-degree ROADM.
How does that sound to you?  Giovanni, Young, and others, does that 
sound good to you?

Best Regards

Greg

---

From: Giovanni Martinelli <[email-masked]>
Date: Tue, 22 Sep 2009 17:14:27 +0200

> How does that sound to you?  Giovanni, Young, and others, does that 
perfect to me!

thx
G

---

From: Jonas Mårtensson <[email-masked]>
Date: Tue, 22 Sep 2009 17:35:51 +0200

Sounds good to me too.

Cheers,
Jonas

> From: Giovanni Martinelli [mailto:[email-masked]]
> Sent: den 22 september 2009 17:14
> To: Greg Bernstein
> Cc: Jonas Mårtensson; Young Lee; [email-masked]
> >> Greg, as you say, the encoding draft specifies an efficient way to
> >> represent the connectivity of a switching node. However,
> the current (uni-directional) examples in section 3.1.1 of
> the framework draft do not illustrate one reason why the
> encoding draft representation is efficient, which is that the
> connectivity constraints for typical ROADM designs are
> "bi-directional", i.e. if ingress port X can (or can't) be
> connected to egress port Y, typically ingress port Y can (or
> can't) be connected to egress port X, assuming the numbering
> is done in such a way that ingress X and egress X correspond
> to the same line side direction or the same add/drop port.
> This makes the connectivity matrix symmetrical (which can be
> taken advantage of by setting the directionality bits of the
> link sets in the encoding draft representation to
> bidirectional). Borrowing Giovanni's (slightly modified)
> proposed 4-degree example with one (potentially
> multi-channel) add/drop per line side port to illustra te :
> >>
> >>
> >> where I5/E5 are add/drop ports to/from line side-3, I6/E6
> are add/drop ports to/from line side-1, I7/E7 are add/drop
> ports to/from line side-2 and I8/E8 are add/drop ports
> to/from line side-4. Note that diagonal elements are zero
> since I assume that loopback is not supported. If ports
> support loopback, diagonal elements would be one.
> >>
> example of
> >>> a 2-Degree unidirectional ROADM. Which represents about
> the simplest
> >>> asymmetric switching  system we can show.
> >>> The  general connectivity matrix  formulation is at its core is
> >>> unidirectional, i.e.,  deals with the potential
> connectivity of each
> >>> ingress and egress pair separately to be generally
> applicable. Note
> >>> that the encoding draft hits the issue of how to represent this
> >>> stuff compactly on the wire.
> >>>
> >>> ports) X  (# of egress ports) and don't forget to include add and
> >>> drop ports. The interesting feature of higher degree
> ROADMs is that
> >>> two ROADMs of the same "degree"  may have very different
> >>> connectivity properties. For example in architectures based on
> >>> add/drop per node versus add/drop per fiber. In your 4-degree
> >>> example Giovanni the number of add and drop ports seemed rather
> >>> small and seems to make it hard to illustrate the
> difference between
> >>> a "drop per node" and a "drop per fiber" style architecture.
> >>>
> section of
> >>> JOCN) that furnishes a significant number of examples of higher
> >>> order and bidirectional ROADMs.
> >>>
> >>> Cheers
> >>>
> >>> Greg
> >>>
> >>>>> Actually, I think the figure you propose is a bit
> confusing for a
> >>>>> couple of
> >>>>> reasons:
> >>>>>
> >>>>>>                ----> |               | -->|
>    |---->
> >>>>>> connectivity matrix only shows what is important for
> the example
> >>>>>> itself).
> >>>>>>
> >>>>>> well hope it's not the main criteria (we can always
> shot for the
> >>>>>> longest
> >>>>>> RFC) ;-)
> >>>>>>
> >>>>>> Cheers
> >>>>>> G
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Cheers
> >>>>>>>
> >>>>>>> Greg
> >>>>>>>

---

From: Young Lee <[email-masked]>
Date: Tue, 22 Sep 2009 13:28:15 -0500

Yes, the suggestion sounds good to me. Thanks.

Young

  _____  

From: Greg Bernstein [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2009 9:51 AM
To: Jonas Mårtensson
Cc: Giovanni Martinelli; Young Lee; [email-masked]
Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM

Although the number of add/drop ports is low we could comment in the text
that this is for simplicity in drawing the figure.
I was thinking of then adding this example to section 3.3.1 after the simple
example of the unidirectional 2-degree ROADM. 
How does that sound to you?  Giovanni, Young, and others, does that sound
good to you?

Best Regards

Greg

Jonas Mårtensson wrote: 

Hi,
 
Greg, as you say, the encoding draft specifies an efficient way to represent
the connectivity of a switching node. However, the current (uni-directional)
examples in section 3.1.1 of the framework draft do not illustrate one
reason why the encoding draft representation is efficient, which is that the
connectivity constraints for typical ROADM designs are "bi-directional",
i.e. if ingress port X can (or can't) be connected to egress port Y,
typically ingress port Y can (or can't) be connected to egress port X,
assuming the numbering is done in such a way that ingress X and egress X
correspond to the same line side direction or the same add/drop port. This
makes the connectivity matrix symmetrical (which can be taken advantage of
by setting the directionality bits of the link sets in the encoding draft
representation to bidirectional). Borrowing Giovanni's (slightly modified)
proposed 4-degree example with one (potentially multi-channel) add/drop per
line side port to illustra
te : 

                             +------------------------+  
Line side-1 ingress (I1) --->|                        |--->  Line side-2
egress (E2)
Line side-1 egress (E1)  <---|                        |<---  Line side-2
ingress (I2)
                             |        ROADM           |
Line side-3 ingress (I3) --->|                        |--->  Line side-4
egress (E4)
Line side-3 egress (E3)  <---|                        |<---  Line side-4
ingress (I4)
                             |                        |
                             +------------------------+
                              | O    | O    | O    | O
                              | |    | |    | |    | |
                              O |    O |    O |    O |
         Tributary Side:     E5 I5  E6 I6  E7 I7  E8 I8

        Ingress Egress Port
 
where I5/E5 are add/drop ports to/from line side-3, I6/E6 are add/drop ports
to/from line side-1, I7/E7 are add/drop ports to/from line side-2 and I8/E8
are add/drop ports to/from line side-4. Note that diagonal elements are zero
since I assume that loopback is not supported. If ports support loopback,
diagonal elements would be one.

Regards,
Jonas

-----Original Message-----
From: Greg Bernstein [mailto:[email-masked]] 
Sent: den 21 september 2009 20:12
To: Giovanni Martinelli
Cc: Young Lee; [email-masked]; Jonas Mårtensson
Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM

 
 
Cheers
 
Greg

Hi,
 
Young Lee wrote:

Hi Jonas,

figures for both 

understanding where 

For your

means Ingress 

 
thx
G

-----Original Message-----
 
Hi Young,
 
Actually, I think the figure you propose is a bit confusing for a 
couple of
reasons:

directions 

confusing.)

Ingress 1(2) 

means that 

 
Regards,
Jonas

-----Original Message-----
 
Hi Giovanni,

matrix per your 

 

    1  0  

Egress 1.

-----Original Message-----
 
Hi Greg,
 
Greg Bernstein wrote:

to Dirk) we 

higher degree    

should also    

point them to section 5.

the scope 

examples the 

connectivity matrix only shows what is important for the example 
itself).

matrix (then how 

   

chairs will be    

            

well hope it's not the main criteria (we can always shot for the 
longest
RFC) ;-)
 
Cheers
G

Cheers
 
Greg

Hi Greg & WSONers,

was         

wondering    

to me a very 

degree         

ROADM as well.

side-1 ingress

Line side-2 

ingress
                        |        ROADM        |

Line         

side-4 egress

Line side-4 

ingress
                        |                     |
                        +---------------------+
                           | | | |  o o o o
                           | | | |  | | | |
                           O O O O  | | | |

consider that    

as  switching constrain.

become an 8x8    

right?.
 
Any thoughts about?

Cheers
G