Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transit vs peering

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 7 Apr 2006 09:05:03 -0400

Richard:
 
I understand this.
 
Let us not correct the mess what others are creating.
 
If all the entities in the network need to be aware of all layers, we would
not be here. We have to create separate standards and charter as well as
requirements. In this case, we all can create solutions based on this basis.

For example, a new work has emerged known as cross-layer/inter-layer
communications especially in wireless where it is seen that, like wire-line
network, it is sub-optimal to consider rigid 7 OSI layers in wireless. To
optimize communications in wireless networks, many research works and
implementations are coming out, and soon some standard works will be done in
many standard organizations including IEEE and IETF.
 
I would advise 3GPP folks, not to put cart before the horse. Let us create
the standards following the established norms across whole world with
step-by-step procedures without creating technical mess and confusions. Let
them have the courage to face this, without being confined in the
self-creating own narrow wall-prison.
 
Unless this is clarified, we all will be fooled though breaking our
fundamental working assumptions.
 
Best regards,
Radhika

  _____  

From: Stastny Richard [mailto:[email-masked]]
Sent: Fri 4/7/2006 8:53 AM
To: Roy, Radhika R.; [email-masked]; Reinaldo Penno; Medhavi Bhatia;
Otmar Lendl; [email-masked]
Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs
peering

Agree, in plain SIP

But,

You should have a look at 3GPP and TISPAN IMS specifications

all the complexities added there is about
making the upper layers aware what is going on in
the lower layers

Richard

> -----Original Message-----
> From: Roy, Radhika R. [mailto:[email-masked]
<mailto:[email-masked]> ]
> Sent: Friday, April 07, 2006 2:44 PM
> To: [email-masked]; Reinaldo Penno; Medhavi Bhatia; Otmar Lendl;
> [email-masked]
> Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-
> transitvs peering
>
> Folks:
>
> Brian is right.
>
> Layer 7 is only signaling-message aware, and has no clue about the
lower
> IP
> network layer routing schemes. In terms of media, it (layer 7) is only
> carrying the identifier of media addresses provided by UAC and UAS. In
> fact,
> media addresses remain in the message body, and a SIP proxy is not
aware
> what is going in the message body.
>
> So, SIP proxy is only ware of signaling of messages between the
proxies
> and
> UAC and UAS assuming that both UAS and UAC are also layer 7-aware
entity.
> One can say that this is layer 7 server-server routing scheme.
>
> Best regards,
> Radhika
>
>
>
>   _____
>
> From: [email-masked] on behalf of Brian Rosen
> Sent: Fri 4/7/2006 8:00 AM
> To: Reinaldo Penno; Medhavi Bhatia; Otmar Lendl; [email-masked]
> Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-
> transitvs
> peering
>
>
>
> > So the SIP proxy is at L7.  If that L7 entity tells a router how to
> route
> > a
> > flow (at L3 or worse, sub IP), then you have a layer violation.
> [[Reinaldo]]
>
> I believe this is where we part ways. I see what you mean, but I
> interpret it differently. I think routing of the media associated with
a
> L7 SIP routing decision is also a L7 routing decision since it is all
> part of the same call.
>
> <BR> Perhaps you would care to explain what protocol is doing this and
how
> it works.  I don't think we are defining new protocols here.  I'm not
> aware
> of any L7 protocol already defined that could reasonably be used to
route
> media with any more specificity than SIP now does (which ultimately is
a
> direct path between UAS and UAC).  You seem to be implying that there
is
> an
> L7 protocol, not SIP, which some peering element would use to cause
media
> to
>
> flow between the UAS and UAC via some set of ?what? L7 Intermediaries?
> Routers? Links? Sub-IP tunnels?  What protocol would that be?
>
> Brian
>
>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
<https://www1.ietf.org/mailman/listinfo/speermint> 
> <https://www1.ietf.org/mailman/listinfo/speermint
<https://www1.ietf.org/mailman/listinfo/speermint> >
>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
<https://www1.ietf.org/mailman/listinfo/speermint> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Apr 2006 09:26:54 -0400

I agree with this, but I don't think we need to start a religious war.

One of the things I think we may be able to agree on is that the peering
point can be assumed to either:

a) Just not be involved with the media

or 

b) Have essentially infinite bandwidth available AT THE PEERING POINT for
the media

Carriers can do all kinds of shenanigans to get the media to the peering
point, but peering is limited by the "pipe" and not the "fabric" (however
the actual L3 packet routing is handled)

If I look around, I think this is the case for the kinds of arrangements we
are contemplating.

It may be that eventually the world coalesces on some ideas to mix L3
routing with L7 routing, and we could then handle more distributed peering
fabrics where there may be limitations at the peering point.  Could we agree
to postpone such discussions for now?

This still allows a quite wide space for media arrangements.  Every carrier
could bring in dumb pipes and just let a router at the peering point shovel
the traffic around.  One could have MPLS tunnels for peering partners that
were address sensitive (all traffic from Pa to Pb goes in a specific
tunnel).

What it doesn't do is put some kind of bandwidth manager function at the
peering point which chooses among multiple paths between Pa and Pb at the
peering point.  At least it doesn't try to standardize such a function.  Is
that satisfactory?

I note that "gate control" has more to do with distributed pinhole firewall
management than with bandwidth management.  I don't think we are going to
deal with such things, are we?  I don't think peering entities have to bring
standardized interfaces to their pinhole firewall for the peering system to
tickle; they just get the SDP in the INVITE and use whatever they want to
open the hole for that flow.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 9:05 AM
To: Stastny Richard; Roy, Radhika R.; [email-masked]; Reinaldo Penno;
Medhavi Bhatia; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] RE: Background Reading on NGNInterconnect-transitvs
peering

Richard:
 
I understand this.

 

Best regards,
Radhika

  _____  

Agree, in plain SIP

But,

Richard

lower
aware
proxies
entity.
a
how
route
a
is
media

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 7 Apr 2006 08:32:55 -0500

>I agree with this, but I don't think we need to start a religious war.

Agree with Brian  ... and if we ENDED one, that would be even better :-)

Thanks,

Spencer