“Well, as we have talked about QoS, why not try to see it at work?”

“Good idea!” – says I

So, let’s take a look at the way 3GPP guys thought of a Dedicated Bearer creation. First of all, these dedicated bearers are structures that:

- have a specific QoS level

- unlike the default bearers, they can be both GBR and non-GBR (but not in the same time, of course) – default bearers can only be non-GBR (as per TS23.401)

- they should only be initiated from the APN, when a bearer is needed in order to send/receive data to/from a specific UE – actually, there is a Bearer Resource Command sent by the MME to the SGW on the S11 – GTP-C interface, which, if the SGW (after asking PCRF), is permitted, receives a Create Bearer Request message on the same S11 GTP-C interface. The MME forwards the Bearer Setup Request/Session Management Request to the eNB (on the S1 interface) – which verifies and deals with the resource allocation, exchanging RRC Connection Configuration messages with the UE. Once the eNB confirms the UE has enough resources to deal with another bearer, it informs the MME about this also, sending it a Bearer Setup Response/Session Management Response, which MME forwards to the SGW as a Create Bearer Response message… Pretty much what the following picture says:

Looking at the S11 interface that I particularly fancy, the first message of interest is the Bearer Resource Command, which has the headers described below. I am omitting the Flags header and any other header that has values described so far in the previous posts…

- Procedure Transaction ID : the ID of the transactions – new concept that appears now (here is 1)

- EBI – EPS Bearer ID : 5 is here ( should be between 5 and 15 – as you know, at most 11 bearers per UE)

- TAD - Traffic Aggregation Description: one of its fields is Operation Code, which, here, is set to Create New TFT, as the output of this transaction will be the creation of a new bearer, with an associated TFT

*** Second to think about stuff: When the PGW intends to create a new bearer (which must have attached a new TFT), it does so based on existing QoS rules on the PCRF. Well, those rules are defined on a per port basis, which means that PGW knows what type of traffic it should transport. And so do UE and MME when sending this command. So, assuming that the traffic triggering my bearer creation is HTTP only, the TFT will need to have a single TFT Filter, on port 80 as a Single Remote Port Type. Assuming that I am intending to send FTP only, the TFT will still have a single TFT Filter, but there will be a Remote port range low limit number of 20 and a Remote port range high limit of 21. Should I want to send both FTP and HTTP, there will be 2 TFT Filters.

- Flow QoS: this one sets the values requested by the MME for the following parameters:

— QCI – QoS Class Identifier – belongs to [1..255] – here is 3

— MBR-U – Maximum Bit Rate for Uplink

— MBR-D – Maximum Bit Rate for Downlink

— GBR-U – Guaranteed Bit Rate for Uplink

— GBR-D – Guaranteed bit Rate for Downlink

The reply from the SGW on this message is the Create Bearer Request from the SGW, which asks the MME to start the negotiation with the eNB in order to allocate resources for this bearer:

- it keeps the same EBI – 5 here

- it also keeps the Transaction ID – 1 here

- and the Bearer Context looks like this:

— EBI – same : 5

— Charging ID : if needed – here 0

— F-TEID of the S1 GTP-U interface of the SGW (!!! Remember that SGW has GTP-C _and_ GTP-U on its interface – which can be a single IP or different IP addresses-recommended – GTP-C does with MME and GTP-U does with eNB – in here it negotiates the GTP-U interface that the eNB will use to send data plane traffic on )

— F-TEID of the S5/S8 GTP-U interface of the SGW – which is headed towards the PGW – may be the same as the previous one or a different one

— Bearer QoS : which holds our beloved QoS values described in the previous eGTP post:

—– the QCI, MBR-U, MBR-D, GBR-U and GBR-D described above

—– the ARP – Allocation&Retention Priority

*** Please read TS23.401 – starting with page 38… Basically, this ARP should be interpreted as “The Priority of Allocation and Retention” – meaning this is a bearer prioritizer: marks a bearer as being more important than another one (the higher the number the more important the bearer); this matter when doing handovers, for instance, because, if you need to cut off some bearers (from lack of resources), you start by cutting off the ones with the smallest ARP values.

*** Still in the TS23.401 (page 38), you will find out that ARP is not a field, but a set of 3 (sub)fields:

— PVI : Pre-emption vulnerability

— PL : Priority Level

— PCI : Pre-emption capability

*** Details of each of them on TS23.401

— EPS Bearer TFT – as the TFT described above

If the MME verifies that everything is OK and the rest of the network is ready to create this new bearer, it replies to the above SGW’s message with a Create Bearer Response message, containing:

- Cause: set to 0 (Request accepted)

- Bearer context, having:

— EBI : set to 6 (the next EBI available) – ! still to verify with the TSs

— Cause: as above

— F-TEID – with the IP address of the S1-U eNB’s interface

— F-TEID – with the IP address of the S1-U SGW’s interface

And now we should be ready for traffic.

Whiiichhh, by the way, is encapsulated as GTPv1! Note to self: log a bug to 3GPP

* first picture is the content of the Bearer Resource Command

* subsequent 2 pictures are from the Create Bearer Request

* last 2 pictures are from the Create Bearer Response

[Show as slideshow]

Tags: 3GPP, ARP, bearers, EBI, eGTP, eNB, GBR, LTE, MME, non-GBR, passion, PGW, QCI, QoS, SGW, TAD, techie, TFT, UE

Iuhuuu

Iuhuuu

hurraaaaayyy

According to their official website: http://www.sfu420.com/?r=1

Six Feet Under is coming to Romania – 4 mai, in Baia Mare, Dacia Hall.

Tags: blackmetal, music

Everybody knows about this Quality of Service thinggie that helps admins to classify traffic and better allocate network and system resources to accommodate traffic needs and also to enforce the policies that exist for each user/groups of users – basically according to the amount of money they pay for this service

In order to enforce a QoS on SAE entities, there are a few things to keep in mind:

A. PCRF – Policy Charging Rules Function device, which basically is a database that holds specific service QoS associations for each UE – this device is interrogated by the PGW in order to find out which QoS is applied on which traffic for each UE that requests a dedicated bearer

B. HSS – Home Subscriber Server, which has _nothing_ to do with QoS; this is a static database that holds information about the UE as is, and no information about any SLA of that UE with the provider

C. Only dedicated bearers hold a QoS level as part of their TFT association

D. The QoS on SAE has multiple variants, dividing the bearers into 2 groups:

– GBR bearers (Guaranteed Bit Rate)

– non-GBR bearers

E. The TFT (Traffic Flow Template – containing the filtering components for the traffic) that is associated with a bearer is not per flow, but per direction:

- TFT-UL (TFT uplink)

- TFT -DL (TFT downlink)

Also, the TFT can be:

- bearer-level

- SDF-level (service data flow level)

Now, we are interested in the GBR bearers. The GBR profile includes the following parameters:

1. QCI – QoS Class Identifier

Rules:

a. 1 QCI corresponds to 1 bearer only

b. 2 services having different QCI values can NOT be on the same bearer (TFT)

c. 2 services having the different QCI values can NOT have the same ARP (see below) value

d. QCI values must belong to [1..255]

2. ARP - Allocation & Retention Priority

Rules:

a. this value has NO influence on QoS

b. this value is set per eNB, following the PGW’s decision

c. it is established by PCRF according to a tuple of —activity type — subscription information — admission policies—

3. GBR – Guaranteed Bit Rate

4. MBR – Maximum Bit Rate

** There are also aggregated GBR bearers: AMBR (this is per APN) and UE-AMBR (the per-non-GBR, per UE rate) — [note to myself] to study more on this!

***Things to consider:

Thinking about the Mobility/Handover scenarios, keep in mind that, when a UE moves from one eNB to another, or from one MME to another, or from one SGW to another, the QoS is enforced on ALL the EPS components. This means that the QCI, ARP, GBR, MBR rates will all be verified on the resources of the destination (destination eNB, destination MME and so on). This means further on that, should at least one of the components not have enough resources to sustain all the QoS of a specific UE, some bearers will be dropped – this, again, is a decision of the SGW, taking into consideration, of course, the signaling came from the rest of the components.

[courtesy of my LTE guru colleagues]

Tags: ARP, bearer, dedicated bearer, default bearer, eNB, GBR, handover, HSS, LTE, MBR, MME, mobility, non-GBR, passion, PCRF, PGW, QCI, QoS, SAE, SGW, techie, TFT, UE

As I was saying in a previous post, Bearers are structures that define a single QoS traffic between eNB – MME – SGW – PGW. They are created via GTP-C (control GTP) negotiation, and have effect on the actual traffic that flows between these entities (GTP-U – User plane). There 2 types of bearers: default bearers and dedicated bearers. While the default bearers are created by default during the Initial Attach procedure, simply stating that the UE is “logged in” the network (and usually no User plane traffic is permitted over these bearers), the dedicated bearers are created specifically when a particular type of application needs to send traffic over the network. If this happens, the network (here read PGW in correspondence with PCRF) looks at its QoS level. Should there be a TFT (associated to a dedicated bearer) already created for that application, the network simply uses that bearer to pass on those IP packets, otherwise it creates a new, dedicated, bearer, with a QoS specific to the needs of the application in question.

So… How is this “default bearer” created after all?

The most usual case is when the MME sends a Modify Bearer Request to the SGW. This message is a simple UDP packet, with destination port 2123, encapsulated as GTPv2. Its content looks like this:

- Flags: showing GTP version (2)

- Type of Message: “Modify Bearer Request”

- Length of Message: 30

- T-EID (Tunnel Endpoint Identifier) of the GTP-C on S11 (between MME and SGW)

- EPS Bearer ID

- F-TEID (Fully Qualified Tunnel Endpoint Identifier) which indicates the type of IP address (here it is IPv4), the type of interface where the bearer would take place (it is S1-U – S1 – User plane, the interface between the eNB served by the MME in question and the SGW in question)

** Why is this S1-U? Why this interface? Why a “U” interface? Because the purpose of the GTP-C is to negotiate the GTP-U part. Basically, via these GTP-C messages I am negotiating which are the GTP-U interfaces that will transfer the actual data. And, as MME is ONLY a GTP-C entity, it has the role of negotiating the bearers that will carry the traffic between the GTP-U entities, here eNB and SGW. So, the GTP-C passes through MME, while GTP-U does not. This is why I can see on the GTP-C message sent from MME to SGW the TEID of a S1 interface, rather than a S11 interface.

- F-TEID IPv4 – this is the IP address of the eNB, in this case 40.0.0.3

** This F-TEID IPv4 is the actual IP address that eNB will use in order to send data-plane packets flowing between UE and PDN. As the path of the GTP-U is between UE – eNB – SGW – PGW – PDN ( the MME only appears in the GTP-C flow), the F-TEID IPv4 address here should have layer 3 connectivity with the SGW IP address. I had a rough time today trying to understand why on earth my GTP-U traffic disappeared, while I was having the eNB and SGW IP addresses on two different subnets and no router to route packets from one subnet to another – smarty, I know

The Modify Bearer Request packet looks something like this:

If the MME has been a good kid (and the UE also), the SGW acknowledges its request and responds with a Modify Bearer Response packet having as Cause : Request accepted. The fields of this packet are the following:

- Flags – indicating the GTPv2 and some other stuff

- Cause – has the IE (Information Element) type, which is 2 here, Cause being Request Accepted and the ID of the Cause is 0 (it should be different than 0 if the request were not accepted)

- Bearer Context – this indicates that the SGW reserved resources for a new context (default one) and instructs the eNB and the PGW to do the same; this field contains the

- – -  EPS Bearer ID : 5

- – - Cause subfield : indicates “Request accepted”

- – - F-TEID: type of IPv4, the interface is S1-U (S1 – User plane between eNB and SGW) and the F-TEID IP is the IP address of the SGW (40.0.0.2)

Basically this message confirms the creation of the Default Bearer, the reservation of the network resources for the traffic flowing over this bearer (if any). The user is officially logged in the network and has the first, most simple and non-priviledged session with the PDN.

The Modify Bearer Response packet looks something like this:

—

Tags: bearers, dedicated bearer, default bearer, GTP-C, GTP-U, LTE, MME, passion, PDN, PGW, S1-U, S11, SAE, SGW, techie, TFT, UE

Pasarea Colibri, one of my favorite rock bands has a song called “Black cat” – I am listening to it obsessively for several days:

http://www.youtube.com/watch?v=qspXArMiflg

Tags: music, passion

The ALU guys were so nice to help us stay in touch with the latest LTE news worldwide.

Today I’ve got an e-mail with a cool link to LTE Buzz , a funky widget that lists the latest feeds related to LTE.

[Show as slideshow]

Tags: ALU, LTE, passion, techie

I’ve always said that, when it comes to Cisco, my brains go boom, temperature increases and I end up having 30 Firefox tab trying to search on cisco.com what on earth some kinky cisco-ish feature does and _how_ precisely.

After the latest IPsec adventure with Cisco’s Customer Support (CCIE Security) which advised me to run commands that were not even available on my IOS (yes, I had previously given them my config and IOS version), I said that whenever I have Cisco-related issues I go straight to my team lead, the guy being able to fix no matter issue I encountered on Cisco – at least on the IPsec side…

Now, I’ve had the honor of having to move an EoU/WebAuth config from a 3750 to a 6500. While I was feeling pretty good about myself being able to configure and understand the way to configure EoU and WebAuth on Cisco (EoU is NAC L2, I am using L2 interfaces in a L2 vlan in mode access and use the “ip admission” command on the L2 interface, while WebAuth gets configured as a fallback to 802.1x using the “dot1x fallback dot1x-www” on the L2 interface), I have now realized that I am FAR FAR AWAY from the truth. I’ve woken up on this twisted 6500, where I have the possibily of configuring:

1. 802.1x – fair enough, I am not using 802.1x here anyways

2. NAC Layer 2 IP / LAN Port IP – which can be configured this way (as per Cisco’s KB)

3. LAN Port IP – which, ignoring their own definition from some KBs, now appears as a “Web-Based Authentication” and gets configured…nowhere says _how_

4. NAC Layer 3 IP / NAC Gateway IP – which should be enabled on L3 interfaces

Router(config)# ip admission name webauth1 proxy http

Router(config)# interface fastethernet 5/1

Router(config-if)# ip admission webauth1

Router(config-if)# authentication order webauth

Router(config-if)# exit

Router(config)# ip device tracking

Router(config)# ip admission proxy http login page file disk1:login.htm

Router(config)# ip admission proxy http success page file disk1:success.htm

Router(config)# ip admission proxy http fail page file disk1:fail.htm

Router(config)# ip admission proxy http login expired page file disk1:expired.htm

5. NAC Gateway IP – which is configured as auth-proxy, this way:

Router(config)# ip auth-proxy name webauth http inactivity-time 60

Router(config)#interface GigabitEthernet3/15

Router(config-if)# description WEBAUTH

Router(config-if)# switchport

Router(config-if)# switchport access vlan 502

Router(config-if)# switchport mode access

Router(config-if)# ip access-group www in

Router(config-if)# spanning-tree portfast edge

Router(config-if)# ip auth-proxy webauth

Router(config)# ip access-list extended www

Router(config)# permit tcp any any eq www

Router(config)# deny   ip any any

The “aaa authentication login default radius” is on. The “ip http server” is on. The “aaa authorization auth-proxy default group radius ” is on also.

Now, I am no EoU, WebAuth, and by far no Cisco guru, but, what gives? Why so many auth methods? And, specially, why the method I use to configure one way on a 3750 (WebAuth using the “auth-proxy” set of commands) is configured some other way on 6500 (WebAuth using the “ip admission <name> proxy http” set of commands) – while keeping the “auth-proxy” set of commands – which here do something else. Why is it so hard to be consistent all over your own set of devices?

I have done 802.1x on Summit (netlogin called in there), WebAuth on Summit and WebAuth on HP switches. None of them seemed so damn confusing I am lost.

Tags: auth-proxy, cisco, eap, EAPoverUDP, EoU, HP, passion, radius, Summit, techie, web-auth

It occurred to me today…how ’bout trying an IPcomp scenario? Of course, looking at RFC 3173, I was very excited about running a test and actually viewing Next Header / Protocol = 108, as the IETF guys say.

Basically, the “Compression” part of this IPsec traffic is negotiated just as  any other protocol: AH, ESP, EAP…via IKE, or manually configured on a device. Now…as I’ve got to devices….good question: _what_ device could I use if I want IPsec IPCompression?

Look at this: http://www.vpnc.org/vpnc-ipsec-features-chart.html. Scroll down to “Features (HTML table). The vendors that actually implement this, as per VPN Consortium (and for some of them I could tell you from direct experience), are CheckPoint, Cisco, McAfee, SafeNet, StoneSF and TeamF1. A bit disappointed that I didn’t have the opportunity of working on all of these devices, I am redirecting my attention to what I do have: a big, shiny and fluffy Debian, with Strongswan installed and xfrm module also on.

So, lets get down to business. I have taken the simplest scenario I could think of at the moment, a transport mode scenario, having as Initiator 192.168.0.10 and as Responder 192.168.0.1. These two hosts negotiate 3des-md5-dh2 algorithms, doing PSK authentication. No PFS, no other kinky stuff. Just basic IKEv2 negotiation. The Strongswan config is as simple as possible.

*Note 1 : on strongswan.org people say that IKEv2 does not support compression – I have run a test with IKEv2 and compression and it works very well But, in order to humor the strongswan guys, I have used IKEv1 in the following scenario

*Note 2 : in order to actually _see_ the encapsulated packets, I have used ESP-NULL Encryption for data encapsulation. Yes, I could have used a NetCocoon analyzer, but that – in the next episode

So: IKEv1, Transport mode, Main Mode, Null Encryption, ESP only, IP Comp:

# ipsec status

000 “network1″: 192.168.0.1[192.168.0.1]…192.168.0.10[192.168.0.10]; erouted; eroute owner: #3

000 “network1″:   newest ISAKMP SA: #2; newest IPsec SA: #3;

000

000 #3: “network1″ STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2488s; newest IPSEC; eroute owner

000 #3: “network1″ esp.525b0b48@192.168.0.10 (0 bytes) esp.5511d8c2@192.168.0.1 (0 bytes) comp.1169@192.168.0.10 comp.527e@192.168.0.1; transport

000 #2: “network1″ STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 2488s; newest ISAKMP

000

Yes, it worked.

Now…I am not sure what exact compression algorithms this Strongswan daemon has, but I can tell you for sure it uses at least DEFLATE (  RFC 2394 ). Cisco on the other hand, uses only LZS (RFC 2395 ) – as far as I have seen – to be updated if anybody else tested it versus DEFLATE.

The process of actually obtaining this cute ESP packets is the following:

a. get the Data from the upper layers of the TCP stack – doh, we need data

b. compress the Data above using the chosen algorithm – you will notice the CPI – Compression Parameter Index – which has well know identifiers for the well known compression algorithms

c. set the Next Header value of the IPComp header to the layer 4 protocol (in this case, TCP)

d. encapsulate everything in ESP, put on the corresponding SPI, set the Next Header value of the ESP header to 108 (0×6c)

e. wrap it up in IP and… we are all set

— You can admire the ESP of IKEv1 in the screenshot attached

Now, what happens differently with IKEv2? I was telling you before the on Strongswan, IKEv2 and AH is a no-no for the moment, ESP with null encryption does a weird thinggie that vmp was so kind to point it out for me (while I was feeling actually quite happy about myself being able to do an IPComp test via IKEv1).

The thing is that, unlike the (correct) way of doing IPComp in IKEv1 (see the aboe a. to e. steps), IKEv2 implementation of Strongswan does a weird thing:

a. get the Data ..blah-blah

b. compress the Data with whatever compression algorithm and put on the IPComp header with CPI value and all

* c. put on another IP header (the internal one, in case of a tunnel mode scenario)

d. put on the ESP header

e. wrap everything up

— Unfortunately, you CANNOT admire the ESP of IKEV2 in a screenshot, because my current wireshark has no idea on how to do decompression of this type of packet. Once it does, I will update

Tags: checkpoint, cisco, compression, Debian, IETF, IKE, IPComp, ipsec, netcocoon, passion, RFC, Strongswan, techie, xfrm

Dupa cum unii dintre voi stiau, tipul ala mare, blond, ras in cap si cu motocicleta (Alex Militaru), si-a facut firma de catering – Smart Food.

De ce? Pentru ca e super simandicos si pretentios si sclifosit si vrea sa aiba mereu procentajul ideal de grasime versus muschi/oase…si ce-o mai fi in corp. De-aia era mereu nemultumit de mancarea pe care o gaseam primprejur si s-a gandit sa rezolve el problema.

Azi am comandat mai multi de la Smart Food si am fost foooarte multumiti. Preturile sunt cam ca peste tot, dar mancarea e fff buna, te saturi, da’ nu simti ca dai pe-afara, nu e grasa si e gatita ca sa isi pastreze componentele hranitoare. Conceptul Smart Food este enuntat de Alex pe pagina de  …Concept

Smartfood s-a nascut din dorinta de a oferi clientilor un gust aparte si un mod sanatos de preparare a produselor, fara aditivi, fara conservanti si fara compromisuri. Conceptul s-a nascut dupa o experienta personala materializata in cautarea unui echilibru alimentar, incercarea de a ajunge la o greutate ideala, completate de sport. Dupa cativa ani de studiu, 20 de kg mai putin si multiple incercari am ajuns la o formula ce ofera deopotriva mancare gustoasa si sanatoasa….

Alaturi de mancarea etichetata frumos sa nu ne incurcam intre noi am primit si sloganuri speciale, ale mele sunt asa:

Supa crema de ciuperci – IKEv2 si niste terci

Pui balsamic – ai grija la degete

Pentru maine am comandat:

supa de broccoli cu branza de capra
somon aglio olio

Abia astept sa vina!!!

Meniul e la adresa :

http://smartfood.ro/meniu.html

Tags: mancare sanatoasa