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

From: "Stastny Richard" <[email-masked]>
Date: Fri, 7 Apr 2006 14:53:22 +0200

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]]
> 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>
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 7 Apr 2006 08:57:59 -0400

Thanks Richard.

I was going to point that out but you already did. A lot of work was
done in this area in 3GPP and TISPAN as Richard mentions. It might be
irrelevant here or not. Time will decide. For those interested:

TISPAN NGN functional architecture
TISPAN gate control protocol
TISPAN services and capabilities requirements

Regards,

Reinaldo

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 5:53 AM
> To: Roy, Radhika R.; [email-masked]; Reinaldo Penno; Medhavi
Bhatia;
> Otmar Lendl; [email-masked]

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 7 Apr 2006 09:30:00 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 6:05 AM
> To: Stastny Richard; Roy, Radhika R.; [email-masked]; Reinaldo
Penno;
> Medhavi Bhatia; Otmar Lendl; [email-masked]
> Richard:
> I understand this.
> Let us not correct the mess what others are creating.
[[Reinaldo]] 

Let me get this straight. Are you saying the work of 3GPP/IMS and TISPAN
is a mess? That's a pretty strong statement.

> 
> 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.
> 
[[Reinaldo]] 
Huh? 

> Unless this is clarified, we all will be fooled though breaking our
> fundamental working assumptions.
> Best regards,
> Radhika
> 
>   _____
> 
> Sent: Fri 4/7/2006 8:53 AM
Bhatia;
> > From: Roy, Radhika R. [mailto:[email-masked]
> <mailto:[email-masked]> ]
> > <https://www1.ietf.org/mailman/listinfo/speermint
> <https://www1.ietf.org/mailman/listinfo/speermint> >
> >
> >

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 7 Apr 2006 13:05:45 -0400

Inline....

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 6:27 AM
> To: [email-masked]; 'Stastny Richard'; Reinaldo Penno;
'Medhavi
> Bhatia'; 'Otmar Lendl'; [email-masked]
> 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?
[[Reinaldo]] 

Fine, I wanted to create awareness because you do not want
<carriers/ISP/what not> which would be the consumers of this
standard/BCP to have to cram together IMS/TISPAN, which uses SIP and
things such as gate control, with this standard (which also uses SIP).
This would be problematic if: 

1) They are in any way conflicting

2) Have huge functionalities gap (Well, some would argue that means more
WG fun)

I mean, we create BCP/standards for the community. We cannot just
plainly ignore something that has been going on for years - that does
not seem very responsible from our part. By that I mean there is a
difference between not bothering about 3GPP, make sure we work together
with their standards and getting in the way of 3GPP. That's my main
concern. If we build something that does not work well with, or gets in
the way of 3GPP that could be a problem for ISP/VSP/Carriers, etc.

I hope it is very clear now.

But I will postpone the discussions.

> 
> 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?
[[Reinaldo]] 

Yes, I was referring more to the scheduling and prioritization of media
and signaling flows (or QoS as you put it some emails ago) than
bandwidth manager.

It seems to me when there is peering, even though we could assume
bandwidth is infinite as you mention, other QoS aspects come into play.

If Layer 5 peering is dynamic such as some advocate, how domain A is
going to let domain B know which flows are media and as such should
receive better treatment.

I have more similar questions. How to reconcile PHBs used in domain A
and B? Or even diffserv markings? Are we going to do that through the
peering policies?

Alternatively could domain B trust domain A to remark media packets at
the border with the dscp that make sense in domain B. Or will domain B
do it?

Or is each domain responsible for looking into the SDP information and
marking/scheduling independently. This is certainly simpler (although
the results are questionable), but seems to defeat somewhat the purpose
of peering, which implies some cooperation.

Not sure this relevant or not to this WG.

> 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.
[[Reinaldo]] 

No, we are not. I was relating more to the QoS treatment aspect of gate
control as mentioned above. More specifically, QoS for media and
signaling flows. 

> Sent: Friday, April 07, 2006 9:05 AM
Penno;
as
wire-
To
done
create
confusions.
Bhatia;