Subject: [Sipping] Draft-Loop-Avoidance || Issue Forking

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 8 Jun 2006 16:11:23 -0500

Hi,

   Consider the following topology
                                                   -------
                                                  | P3  |
                                                   -------
----------                 ---------                  |
|        |                 |         |                 |
|  P1  |---------------- |  P2   | ----------------
|        |                 |         | ---------------
---------                  ----------                | 
                                                     |
                                                 -------
                                                |  P4 |
                                                 -------
Note : Bindings are given with proxy names only. For accuracy it is
<userName>@<domainName for which Proxy is responsible>

1)Loop caused in branch doesn't have multiple hops. 
    Loop is existing in P2 to P3 branch. i.e. ( P2 <---> P3)  And P2 to
P4 branch is loop free. (P2 --->P4)
    And then you add binding between P1 --> P2.

   When bindings are added at P2 or P3 then it should be able to find
the loop between them. This looped bindings should
   not be used for retargeting of testing for binding addition of P1 -->
P2 
   P2 to P3 state is "Loop removal Needed" at Proxy P2. Same is for P3
to P2 binding at Proxy P3.

2) If loop caused has multiple hops in a branch i.e.  P1 -> P2 -> P3 ->
P1 . 
 
  case A)  Binding P1 -> P2 and P2 -> P3 and P2 -> P4 are added without
any problem.
               Now when P3 -> P1 is to be added. P3 can find itself in
the forked OPTIONS by P2.
 
              It can mark P3 -> P1 for Loop Removal needed. It can
notify other proxies for P1, P2 also.
              Latest binding causing loop is  not added. And further
request will be completed only via P4 . If request is forked by P2  to
P3
              P3 can return "Loop Removal Needed".
              If P2 doesn't use P3 for forking, refer point 3 below.

  Case B) Binding P1 -> P2 and P3 -> P1 are added without any problem.
               Now when P2 -> P3 and P2 -> P4 needs to be added.
               Here P2 can mark P2 -> P3 for "Loop Removal Needed"
without any problem and P2 -> P4 will be added.

  Case C) Binding  P2  --> P3, P2 --> P4 is added first. Then P3 --> P1
is added. There is no issue with this.

                Then P1 --> P2 binding is to be added
                P1 will itself in the detailed contents of 483 through
the forked branch of P2-> P3. 
                It can mark P1 --> P2 "Loop Removal needed". And does
not give weightage to 200 OK coming from P4.

                Ideally here P1 --> P2 should have been added, and the
bindings P2--> P3 , P3 --> P1 should have been 
                marked for "Loop Removal Needed". To achive this, we
require more  NOTIFY going from P1. 

                If there is loop in any forked branch by addition of a
binding, it will come back to Proxy where bindings are
                being added, if all branches are touched for testing.

3) If forking proxy doesn't fork in parallel but attempts serially

For example Refer Case C of point 2 

Here If P2 doesn't fork in parallel, and forwards the OPTIONS to P4 and
gets 200 OK. In this case with the new option tag defined for this
extension, we will ask forking proxy (P2 here) to verify all the
branches locally, if they are not used. If we don't want to do this way,
periodic audit at P2 for P3 branch will catch it.              

4) I think the above cases in 1) and 2) will be common in other
topologies someway from the loop detection point. I may be wrong here.

Thx
Samir

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP