Not doing what is committed in planning meeting

I coach all involved that changes in the middle of Sprint can be done but not without negotiation and agreement of the Development Team (DT).  The DT owns the Sprint and what is included in the Sprint Backlog.  If someone outside of the DT wants to add something to the Sprint, the DT has the right to say no.  If they feel that bringing those items into the Sprint is valid, then a conversation should ensue about what items in the current Sprint Backlog should be removed as the DT has already planned a Sprint based on what the feel comfortable forecasting can be done during the Sprint. There should also be discussion on whether the Sprint Goal is negated by adding these stories and Sprint cancellation should be discussed.  Canceling a Sprint is not something you should do lightly or often.  But doing all of these things can show how the behavior of management is negatively impacting the Scrum Team's ability to consistently deliver value. 

How do you handle moments when management is forcing your team to include...

This is the root of the problem. The Product Owner should be the intermediary for the Scrum Team with management.  They should be willing to push back, able to illustrate how their new request will be included in the Product Backlog and use the feedback of management to identify where these new stories will be ordered in the Product Backlog. 

In my opinion, a management that is "forcing" does not really understand or appreciate the agile mindset.  As Scrum Master some of your responsibilities to the organization are

• Leading and coaching the organization in its Scrum adoption;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team;

I see a lot of opportunity for you in those statements. 

How do you handle moments when management is forcing your team to include some new PBI's or implement new functionality in the middle of the sprint???

Who in management actually wants Scrum to be implemented properly, so its benefits can be realized? Has that senior sponsor been made aware of the interference you describe?

It seems like the first error is considering the outcome of Sprint Planning as a commitment. It's a forecast - based on the team's recent history and all available information, the team believes that they can accomplish a certain goal by completing some or all of a set of work (Product Backlog Items) within the Sprint timebox. However, during the course of that timebox, things may come up that interfere with the forecast from being realized. The purpose of the Daily Scrum is to identify these things and determine how to replan them.

As far as mid-Sprint changes go, that ultimately needs to be a discussion. First, the between the Product Owner and the stakeholders to determine what the new work is, where it fits in relative importance, and if it makes sense to bring this to the Development Team. Second, between the Product Owner and the Development Team to determine if it's possible to incorporate the changed scope of work into the Sprint and what would the result be on the team's plans to achieve the Sprint Goal. Both discussions can, as needed, be facilitated by the Scrum Master. The Scrum Master should also be coaching stakeholders on the Scrum framework.

If the team is frequently interrupted mid-Sprint with changes, I'd want to do a deeper dive into this. I'd want to make sure everyone understands the underlying theories behind Scrum and make sure that the current instantiation is appropriate with respect to synchronization between the Scrum Team and the stakeholders.