{"id":158,"date":"2018-01-07T22:04:09","date_gmt":"2018-01-07T22:04:09","guid":{"rendered":"https:\/\/www.kuncar.net\/blog\/?p=158"},"modified":"2018-01-09T00:45:19","modified_gmt":"2018-01-09T00:45:19","slug":"ethersam-y-1564-explained","status":"publish","type":"post","link":"https:\/\/www.kuncar.net\/blog\/2018\/ethersam-y-1564-explained\/","title":{"rendered":"EtherSam (Y.1564) explained"},"content":{"rendered":"

\"\"This is the last article (at least for now) from the series about testing methodologies and testing standards. I will cover some bits and pieces in the region of testing in general but it won\u2019t be as heavy on the theory as I want to write some \u201chands-on\u201d scenarios for combined use of Wireshark and PackEth as well as about some multicast scenarios. Also I will be doing more Cisco and Juniper stuff so it is quite likely I will be blogging some configs and labs. Anyway enough about the future plans and let\u2019s start with the topic at hand.<\/span><\/p>\n

Introduction<\/span><\/h3>\n

The ITU-T\u00a0Y<\/b>.1564 also more commonly known as\u00a0EtherSam<\/b>\u00a0(which originated in the old name of the standard ITU-T\u00a0Y<\/b>.156sam<\/b>)\u00a0is a service activation test suite whose goal is to allow for rapid link testing in deployment of services. The main advantage of this test is that it allows for testing of SLA (Service Level Agreements) while deploying new service and it can do that disregarding the Physical topology (i.e. it can verify end-to-end SLA even in live environment with live traffic flowing through the network).<\/span><\/p>\n

There is few serious considerations in general that make this test suite bit awkward to use.<\/span><\/p>\n

First one is that this is a very new standard (initiated in 2009, published 2011) and is still changing as new drafts are still being issued.<\/span><\/p>\n

The next rather serious problem is that this test suite is for \u201cservice activation\u201d which means in normal language that it is no good for lab testing as it doesn\u2019t really stress the equipment. The reason is that the\u00a0EtherSam<\/b>\u00a0is designed around the idea of rapid deployment of new links\/services in Telcos (I will write about the disadvantages of the design in later).<\/span><\/p>\n

The last issue is that as a new standard it is rather unknown among network engineers so it takes some education before it can be used.<\/span><\/p>\n

Traffic parameters<\/span><\/h3>\n

The theory behind this test suite is somewhere half way through between the RFC2544 and BERT tests as it tried to get the best of both while achieving similar results to both. Lets start with definitions as they are the most important. In\u00a0EtherSam<\/b>\u00a0you can configure multiple concurrent services and each service \u00a0can have following 4 parameters:<\/span><\/p>\n

    \n
  • CIR \u2013 Committed Information rate<\/span><\/li>\n
  • CBS \u2013 Committed Burst Size<\/span><\/li>\n
  • EIR \u2013 Excess Information rate<\/span><\/li>\n
  • EBS \u2013 Excess Burst Size\u00a0<\/span><\/li>\n<\/ul>\n

    This is not as complicated as it might seem at this point. These values are only used to set the SLA. The CIR defines the minimal amount of traffic within the available bandwidth and must be always fulfilled. If there is only CIR specified on the links\/services it is a good practice to have some amount of bandwidth allocated to CBS as it will allow for a small overshoot in case of traffic burstiness. Obviously one might need more flexibility in how much traffic to pass through (like over-subscription) where some frame loss is acceptable in exchange for more data being delivered. That is the Excess Information Rate. As it is obvious that once EIR is in place the data from CBS would be calculated as part of EIR so CBS setting loses its meaning. If you want to get little more flexibility in case of having more bursty traffic you can specify EBS on top of the EIR.<\/span><\/p>\n

    Traffic coloring<\/span><\/p>\n

    In the paragraph above I have described the two out of three traffic types that exist in\u00a0EtherSam<\/b>\u00a0which would be reffered to as a green traffic (CIR+CBS) and yellow (EIR+EBS). The standard also defines a red traffic which is a traffic non-conforming to either CIR or EIR. In effect based on the\u00a0EtherSam<\/b>\u00a0methodology this traffic should never be passed and should be dropped. This look like a absolutely trivial and obvious thing but it has one very serious consequence in deployments with over-subscription in place \u2013 you must define the EIR as the \u201cshared\u201d part of your QoS with specific size allocated to it. So having a random amount of free-to-grab bandwidth for the tested service will result in failing the test as passing red traffic is a fail criteria on\u00a0Y<\/b>.1564.<\/span><\/p>\n

    \"Traffic<\/span><\/p>\n

     <\/p>\n

    Bandwidth profile parameters \u2013 Coupling flag and Color mode<\/span><\/h3>\n

    I am putting description of these two parameters at this place just for the sole reason that they are defined in the standard but I would like to stress out that I haven\u2019t seen them implemented in any testing equipment so far so this section will be rather short and most people can just skip it as it has little to none practical use (at least at the time of writing). These two parameters allow for the metering algorithm to be adjusted and thus change the result. Also they are valid only in certain scenarios.<\/span><\/p>\n