*_ Dear All: Plz Check following issue found in
draft-ietf-pwe3-segmented-pw-00.txt and solutions we give
below , Plz
give your valable comments on it . _*
*_Looping of Switch VCs_*
*_ _*
/_Problem Description:_/
Consider the case as shown in the figure where a loop of SPE
[switch VC]
is configured. In this case when a switch VCs are configured in a
loop,
we may end up in a situation where our request message are
infinitely
looped.
In implementation where we opt to not store the unmatched remote
mapping
information, we use the request message to get the information again
from the peers. Implementation that requires this feature to be
enabled/disabled from a command require request to get the mapping
information again.
In the case thus described we end up in looping the request message
infinitely.
SPE1
/ \
/ \
/ \
/ \
/ \
/ \
SPE2------------SPE3
Suppose S-PE1 send request to S-PE2 and S-PE3. On receiving this
request
at S-PE2, we search and locate the corresponding Switch-VC
configured;
the operation now would be to send the request message to the other
segment (PW) of this switch VC i.e. to S-PE3. When S-PE3 receives
this
request, find the switch VC and would send the request to the other
segment (PW) i.e. to S-PE1. The S-PE1 would continue to send request
message as described above. Thus the request message would loop
around
in this topology for ever.
/_Solutions:_/
1) PW Switching point TLV
2) Hop Count
3) Time To Live (TTL)
*PW Switching point TLV*
The draft /draft-ietf-pwe3-segmented-pw-xx/ [refer section 6.1.4]
mentions the use of PW Switching point TLV in the mapping/
notification
message. This can be extended to the request message and the
looping can
be avoided.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| PW sw TLV (0x096B) | PW sw TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type Values are assigned as follows:
Type Length Description
0x00 0 Reserved
0x01 4 PW ID of last PW traversed
0x02 variable PW Switching Point description string
0x03 4 IP address of PW Switching Point
(Optional)
We can attach the LSR-ID of S-PE every time we generate / send the
request message, on receiving the request message a check is made to
make sure that the router LSR ID is not present in this TLV. In the
above case S-PE1 would receive the request message with the LSR-
ID of
S-PE1, S-PE2 and S-PE3. We discard the request message as S-PE1
LSR ID
is present in the switching point TLV.
In case of request message loop detection we do not send label
release
as done in the case of mapping/notification.
*Hop Count*
* *
Another solution to avoid the looping of request message would be to
append the Hop Count as done in draft /draft-ietf-mpls-rfc3036bis-
xx/
[refer section 3.4.4]. This would calculate the number of hops the
request message propagates.
Type Length Description
0x04 4 Hop Count of PW Switching Point traversed
Follow the procedure to discard the request message once the Hop
Count
reaches a specified maximum value.
*Time to Live [TTL]*
* *
Based on the above idea one can use a TTL field to avoid infinite
looping of request messages. As the message traverse through the
hop,
the TTL value is thus decremented. The message is discarded when the
field value is zero.
Type Length Description
0x04 4 TTL field value
The field can be initialized to specified value.
_ _